Version of Dependent Package in APACK

[mbtools]

Hi Alexander,

I think your abap-shield implementation is very cool (geeky even). In general, it's working well but I have several private repositories and don't think there's a way to make shields work with that, or is there?

So instead, I created a public repo with an APACK that contains just the version info of all my private repos. My feature request is therefore to enhance this solution to retrieve the version of a dependent package from the APACK manifest.

Here's my APACK:
https://github.com/mbtools/mbt-versions/blob/master/.apack-manifest.xml

I could imagine using the following syntax:

https://shield.abap.space/version-shield-json/$TYPE/$OWNER/$REPO/.apack-manifest.xml/$ARTIFACT_ID

I put examples of this into my readme (obviously not working):
https://github.com/mbtools/mbt-versions/blob/master/README.md

Best wishes,
Marc

[sbcgua]

Hi Marc, Greetings to Toronto (if I understood well) :)

Yeah, private repos are not that clear conceptually. Why display the badge if no-one sees it? And if display, how to store access credentials? Certainly not in badge URL. Then it means some kind of storage at server side which would complicate the solution a lot to make it secure. Potentially I can imagine a private instance of shield generator that would add a predefined http header with auth info. Should be relatively easy to implement: auth key can be defined in an env var and copied to AWS during deployment. Could be interesting feature, but please open a separate issue for this. PR's also welcome :)

Sub packages from apack. Interesting idea. But I would like to ensure a more universal approach to align with potential future features. Maybe adding a type of query right after APACK filename. E.g. .../.apack-manifest.xml/dependencies/$GROUP_ID/$ARTIFACT_ID.

So that

• if the file path is .apack-manifest.xml and no params => use apack version
• if the next param is dependencies => expect more params with group and id (both are requested because id maybe not unique by design) and search for $GROUP_ID/$ARTIFACT_ID in deps

I can have a look on it during the weekend. Also PR's are welcome if you prefer coding this yourself - let me know.

[mbtools]

Toronto is indeed my home. But I’m living in Nice, France with my family currently… We are quite international. 😉 Private repos can be accessed by several people. So a badge makes some sense. But let’s keep it simple. Using the path to the version within the APACK sounds good. This might work for XMLs in general (if there are different formats in the future). I’m very good in ABAP but unfortunately not so great in xml/xpath/jquery. Cheers, Marc From: Alexander Tsybulsky <[email protected]> Sent: Wednesday, February 12, 2020 18:18 To: sbcgua/abap-package-version-shield <[email protected]> Cc: Marc Bernard <[email protected]>; Author <[email protected]> Subject: Re: [sbcgua/abap-package-version-shield] Version of Dependent Package in APACK (#1) Hi Marc, Greetings to Toronto (if I understood well) :) Yeah, private repos are not that clear conceptually. Why display the badge if no-one sees it? And if display, how to store access credentials? Certainly not in badge URL. Then it means some kind of storage at server side which would complicate the solution a lot to make it secure. Potentially I can imagine a private instance of shield generator that would add a predefined http header with auth info. Should be relatively easy to implement: auth key can be defined in an env var and copied to AWS during deployment. Could be interesting feature, but please open a separate issue for this. PR's also welcome :) Sub packages from apack. Interesting idea. But I would like to ensure a more universal approach to align with potential future features. Maybe adding a type of query right after APACK filename. E.g. .../.apack-manifest.xml/dependencies/$GROUP_ID/$ARTIFACT_ID. So that * if the file path is .apack-manifest.xml and no params => use apack version * if the next param is dependencies => expect more params with group and id (both are requested because id maybe not unique by design) and search for $GROUP_ID/$ARTIFACT_ID in deps I can have a look on it during the weekend. Also PR's are welcome if you prefer coding this yourself - let me know. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AOJQIHHGCICTVMK636HD6ZTRCQVOLA5CNFSM4KTHVXS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRTOIQ#issuecomment-585316130> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOJQIHDJDT2WQSEDBLD432TRCQVOLANCNFSM4KTHVXSQ> . <https://github.com/notifications/beacon/AOJQIHHTO7ZZ6V5O55CPVF3RCQVOLA5CNFSM4KTHVXS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRTOIQ.gif>

[sbcgua]

beta is done. Please try, but currently prepend dev. at the beginning. This code is not in the main function yet.

https://dev.shield.abap.space/version-shield-json/github/mbtools/mbt-versions/.apack-manifest.xml/dependencies/github.com/mbtools/mbt-bc-cts-req

[mbtools]

Hi Alexander,

I tested it. First page load had two of the images broken. The one you tested with, worked fine. However, after a refresh, all shield badges are working great!

https://github.com/mbtools/mbt-versions

👍
Marc

[sbcgua]

OK, so it is productive. You can switch to shield.abap.space without dev prefix :) I will deactive dev soon.

P.S. Ctrl+F5 - yeah, browsers cache stuff, so quite typically need full refresh for the shields