Setup Github Actions that deploy our hello-strongbox-* to the Github Package Registry

[carlspring]

Task Description

We need to create a Github Action for the strongbox-examples that deploys the artifacts for each of layout providers (that we have an image for) to the Github Package Registry for the strongbox-examples.

You will need to create a fork and set this up in your fork first.

Tasks

The following tasks will need to be carried out:

• Create a Github Action that deploys the hello-strongbox-ant-ivy into the Github Package Registry. This uses the Maven 2 layout provider.
• Create a Github Action that deploys the hello-strongbox-gradle into the Github Package Registry. This uses the Maven 2 layout provider. (@j4ckofalltrades)
• Create a Github Action that deploys the hello-strongbox-maven into the Github Package Registry. (@BjoernAkAManf)
• Create a Github Action that deploys the hello-strongbox-npm into the Github Package Registry. (@j4ckofalltrades)
• Create a Github Action that deploys the hello-strongbox-nuget-chocolatey into the Github Package Registry. This uses the Nuget layout provider. (@j4ckofalltrades)
• Create a Github Action that deploys the hello-strongbox-nuget-mono into the Github Package Registry. This uses the Nuget layout provider. (@j4ckofalltrades)
• Create a Github Action that deploys the hello-strongbox-sbt into the Github Package Registry. This uses the Maven 2 layout provider. (@j4ckofalltrades)
• Provide a list of detailed configuration/set up steps for us to do on our side.

Task Relationships

This task:

• Is required for:

Useful Links

• Github Actions
• Github Packages
• Github Package Registry
• Github Actions: Publish To Github Packages
• Github Actions: Hello, World!
• Github Actions: Authentication In A Workflow
• Act: An Environment For Testing Github Actions On Your Local Machine

Help

• Our chat
• Points of contact:
  • @carlspring
  • @sbespalov
  • @steve-todorov

[BjoernAkAManf]

Hi,

this sounds easy. Should the actions somehow also use an installed strongbox installation or merely build + deploy to github actions. While the former sound complicated, the latter seems "pointless"? Am i missing something here?

Would gladly help otherwise :)

[carlspring]

Hi @BjoernAkAManf ,

The point of this task is so that we can later on use these dependencies for testing Strongbox's behaviour when proxying to the Github Package Registry. I will create a follow-up task for this as well. So, to answer your question -- no, it should not be deploying to Strongbox at all right now, just to the Github Package Registry.

Feel free to pick this up! :)

@j4ckofalltrades might pick up some of the sub-tasks as well.

[BjoernAkAManf]

Ah thanks! Guess i'll go and write some github actions code then 😄 .

[BjoernAkAManf]

Took more attempts than i wanted it to, however now it builds jars into the package repository.
Just to clarify, is that what you meant by:

• Create a Github Action that deploys the hello-strongbox-maven into the Github Package Registry.

See:
https://github.com/BjoernAkAManf/strongbox-examples-actions/blob/main/.github/workflows/maven.yml
https://github.com/BjoernAkAManf/strongbox-examples-actions/packages/466292

[carlspring]

Awesome, thanks! :)

So, you now have the Maven one covered! Would you like to do the rest of the ones that use Maven repositories as well (first)?

[BjoernAkAManf]

Sure i can do that.

[j4ckofalltrades]

@BjoernAkAManf @carlspring I'm currently looking into hello-strongbox-npm, fyi. Also found this cool repo that lets you run GitHub Actions locally.

Update: Looking into hello-strongbox-nuget-* next.

[carlspring]

Thanks, @j4ckofalltrades ! This project looks quite useful and I'm sure we'll be using it to try out more of our Github Actions with it in the future!

cc: @steve-todorov

[carlspring]

@BjoernAkAManf : How are things going with the Maven-based actions?

[j4ckofalltrades]

Just an fyi regarding authentication in GitHub Action workflows, this pertains to the GITHUB_TOKEN secret that is used when publishing artifacts to the GitHub Package Registry. This is automatically provided by GitHub for every repository and can be referenced with ${{ secrets.GITHUB_TOKEN }}.

See https://docs.github.com/en/free-pro-team@latest/actions/reference/authentication-in-a-workflow#about-the-github_token-secret for more info.

[carlspring]

Thanks for the clarification, @j4ckofalltrades ! :)

There's something else that we'll need to address -- the non-Maven-based tool have no concept of snapshots, which means that every time we merge a pull request, the NPM, NuGet and so on Github Actions will fail. Is there a reasonable way in which we can handle this for these? Can we remove the artifacts before deploying them? (They're all using fixed versions such as 1.0.0, right?).

cc: @steve-todorov

@j4ckofalltrades ,

Please, feel free to pick up the Maven and SBT ones as well. We haven't heard back from @BjoernAkAManf, nor seen a pull request for them yet, so I assume it would be safe to proceed with them as well. (Please, feel free to give us a shout, if this is not so, @BjoernAkAManf).

[j4ckofalltrades]

@carlspring

Can we remove the artifacts before deploying them? (They're all using fixed versions such as 1.0.0, right?).

Unfortunately this isn't possible for public repos / packages. From GitHub docs:

About public package deletion
To avoid breaking projects that may depend on your packages, you cannot delete an entire public package or specific versions of a public package.

Under special circumstances, such as for legal reasons or to conform with GDPR standards, you can ask GitHub Support to delete a public package for you, using our contact form.

We could maybe skip the publish step as an alternative e.g. nuget push has a -SkipDuplicate option which does this.

[carlspring]

We could maybe skip the publish step as an alternative e.g. nuget push has a -SkipDuplicate option which does this.

Yeah, we should probably do this.

[carlspring]

@j4ckofalltrades : Could you please make the artifact names more consistent? If possible, they should all be using the following format: hello-strongbox-*?

[BjoernAkAManf]

Sorry to reply so late, have been unexpectedly busy the last couple of days.

I'll add the maven artifact to the github repository now, but otherwise i'll probably wont be able to help the next days.

[carlspring]

Thanks @BjoernAkAManf ! I think that it will be better, if @j4ckofalltrades does the remainder of the sub-tasks, as he's already done with most of the work anyway.

@j4ckofalltrades , @steve-todorov : Could you please review strongbox/strongbox-examples#28? Thanks! :)

[carlspring]

@j4ckofalltrades , @BjoernAkAManf , @steve-todorov ,

There is another problem with the deployment of all these artifacts that I've realized. Basically, when an example sub-module has been changed, we will need to bump the versions for all of the other ones as well, because if they have already been deployed to the Github Package Registry, then the deployment for all of them will fail.

Do you guys have any suggestions on how we could easily sort this our for all of them? Should we use the maven-versions-plugin to bump the version on each merged to master (and add a step for this as well)?

[steve-todorov]

maven-versions-plugin will only work for maven artifacts (sbt, mvn and maybe groovy?). npm uses the package.json and it would need additional work to update the version. We could try doing it :)

However, we'll then need to address this as well:
strongbox/strongbox-examples#28 (comment)

[j4ckofalltrades]

One other option is to append the latest commit hash (maybe trimmed to first ~6-10 characters) to the version number. like in https://maven.apache.org/maven-ci-friendly.html and it should be fairly simple to do in other non-Maven based artifacts as well.

GitHub Actions provides it via the GITHUB_SHA environment variable.

[carlspring]

Another option would be to switch the version to YYYYMMDD-hhmm or something along these lines.

[carlspring]

The hash would probably be easier and cleaner, but it would also be less human-intelligible (and it would be hard to tell what the latest version is, unless you look it up via the commit history). Not that anyone would really be using these artifacts for anything else than testing our integration with the Github Package Registry via Strongbox.

[j4ckofalltrades]

@carlspring

Okay let's go with the append timestamp yyyyMMdd-hhmm to the version approach. I've opened pull requests for updating the existing gradle workflow strongbox/strongbox-examples#31 plus the other remaining mvn-based ones - sbt strongbox/strongbox-examples#30 and ant-ivy strongbox/strongbox-examples#32.

If all good then it should also be applied to the maven workflow.