Version of Dependent Package in APACK

mbtools commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com Sent: Wednesday, February 12, 2020 18:18 To: sbcgua/abap-package-version-shield abap-package-version-shield@noreply.github.com Cc: Marc Bernard marc@marcbernardtools.com; Author author@noreply.github.com 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 https://github.com/sbcgua/abap-package-version-shield/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

sbcgua / abap-package-version-shield

Version of Dependent Package in APACK #1