bug(ci): Not using latest release action with "v1"

[celanthe]

Issue/Bug description:

When running the community action maven release workflow in the spring-zeebe repository, all workflows successfully build with the exception of example/spring-zeebe-example-worker ................ FAILURE [ 1.578 s]

This failed workflow run can be viewed in more detail at: https://github.com/camunda-community-hub/spring-zeebe/runs/4372925957?check_suite_focus=true

Full error text: Error: Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy-staged (default-cli) on project spring-zeebe-example-worker: Failed to deploy artifacts: Could not transfer artifact io.camunda:spring-zeebe-example-starter:jar:1.2.7-20211130.202345-1 from/to central (https://oss.sonatype.org/content/repositories/snapshots/): authorization failed for https://oss.sonatype.org/content/repositories/snapshots/io/camunda/spring-zeebe-example-starter/1.2.7-SNAPSHOT/spring-zeebe-example-starter-1.2.7-20211130.202345-1.jar, status: 403 Forbidden -> [Help 1]

The 'status: 403 Forbidden' has led me to question if the settings.xml are correct for example/spring-zeebe-example-worker, as they may need to be updated due to the migration of Maven artifacts to Artifactory, particularly if they were/are stored on a local machine.

The latest release action version v1.0.9 does not persist unless added manually, and continues to default to using @v1 as seen in https://github.com/camunda-community-hub/spring-zeebe/commit/bfb4677ac8c6bd0b470524b5a08c0109e47a619e which leads to the above 403 error and failing workflow.

Steps to reproduce the issue/bug

1. Run workflow as intended to automatically release to Maven Central using latest version v1.0.9 of the Community Action Maven Release tool

What's the expected result, or what did you expect to happen?

• All builds complete successfully, using v1.0.9 of the Community Action Maven release

What's the actual result?

• All builds are successful with the exception of example/spring-zeebe-example-worker ................ FAILURE [ 1.578 s], this causes the entire workflow run to fail.

Platform details

TBD

Desktop (please complete the following information):

• OS: OSX
• Browser Chrome
• Version: GitHub IDE

Additional details/clarification questions

Suggest confirming that the account in question has the privileges needed in Artifactory/Maven central to reach Maven. Also suggest confirming settings.xml is configured correctly for the failing build. If needed, suggest creating an API key in Artifactory and updating local maven m2 settings.xml.

Is it possible we have exceeded a quota with Maven? I wouldn't think that is the case, but might be worth looking into?

Data Source[s]: https://stackoverflow.com/questions/59686900/maven-nexus-issue-authorization-failed-for-403-forbidden

https://stackoverflow.com/questions/65663325/403-forbidden-when-trying-to-install-arcgis-java-dependency-with-maven

https://github.com/jitpack/jitpack.io/issues/3388

https://github.com/sonatype-nexus-community/nexus-repo-github-action/issues/4

[berndruecker]

Hi @celanthe - I think the error is much simpler: It tries to access https://oss.sonatype.org/ for an io.camunda artifact, which should go to https://s01.oss.sonatype.org/, which is exactly what we introduced with newer versions of the Maven Release Action. So this parameter here is NOT used: https://github.com/camunda-community-hub/spring-zeebe/blob/master/.github/workflows/mvn-release.yml#L30. I think this proves that an old version of the release action is used, so not the latest v1.0.9.

[celanthe]

Hi @berndruecker! Oh, I see. If I'm understanding you correctly, would that mean that by updating L30 of default: "oss-maven-central" to instead use the value listed in https://github.com/camunda-community-hub/spring-zeebe/blob/master/.github/workflows/mvn-release.yml#L30 that might solve this issue? If so I am more than happy to make that change and see if that resolves this issue.

[berndruecker]

No. Changing the default would mean, that projects with org.camunda will have the problem instead of io.camunda. So it is just swapping things around.

The problem is, that the config option in line https://github.com/camunda-community-hub/spring-zeebe/blob/master/.github/workflows/mvn-release.yml#L30 is not read by the action in v1.0.0 - only in v1.0.9 - which seems not to be used when I write v1

[celanthe]

Hi @berndruecker! I did some digging into this further along with assistance from one of my friends who works at GitHub and their team. They came back to me with a few options:

1. Someone else asked a similar question to ours of the SemVer team: https://github.com/semantic-release/semantic-release/issues/1478 and what was interesting there was that they found an action that seems to do exactly what we're looking for. A sample workflow is at: https://github.com/Actions-R-Us/actions-tagger#sample-usage and the main repository is https://github.com/Actions-R-Us/actions-tagger if you'd like to take a look. I think it might solve our problem!

2. If the above doesn't work, we might be able to move the major version tag @v1 to point to the Git ref of the current release which in this case would be v1.0.10. Though it would alter history we could also force push the tag itself, and linked the following blog post as an example of how to do so: https://pakstech.com/blog/move-git-tag/

I look forward to hearing from you and would be happy to help implement the https://github.com/Actions-R-Us/actions-tagger workflow into our existing action and see if that works!

[berndruecker]

@celanthe: Interesting! This looks good to me - and I agree that it sounds better to automate overwriting the tag via the https://github.com/Actions-R-Us/actions-tagger. I think, then we could simply introduce a latest tag for the action which shall be used everywhere. WDYT?

Would you go ahead and add this or shall I?

[berndruecker]

Shouldn't there be a "latest" tag now? https://github.com/camunda-community-hub/spring-zeebe/runs/4448864671?check_suite_focus=true Error: Unable to resolve action camunda-community-hub/community-action-maven-release@latest, unable to find version latest

[berndruecker]

Plus: I think we should also update the readme once this is really fixed

[celanthe]

@berndruecker I agree completely. I will look into this. Not sure why there isn't a 'latest' tag now...Will report back ASAP.

[berndruecker]

Also latest v1.0.11 seems not to work: https://github.com/camunda-community-hub/spring-zeebe/runs/4448883262?check_suite_focus=true

Error: Unable to resolve actionActions-R-Us/actions-tagger@latest+with%3A+publish_latest_tag%3A+true, unable to find versionlatest with: publish_latest_tag: true

[berndruecker]

Maybe worth to setup a small test project where you can verify it is working as intended?

[celanthe]

Hi @berndruecker -- I attempted to try one more fix with #31.

I am able to verify on my machine with git -tag that a latest tag was created and points to https://github.com/camunda-community-hub/community-action-maven-release/releases/tag/latest.

I am also working on setting up a test workflow in the https://github.com/camunda/infra-github-demo repository that I can test this action on in case it continues to be flaky.

[celanthe]

Update: I've also opened a support ticket w/GitHub about this.

[berndruecker]

OK - I could now verify this @celanthe: Using @v1 still does not work (https://github.com/camunda-community-hub/spring-zeebe/actions/runs/1607303855), but it might be as simple as there is an existing tag for this pointing to an old version: https://github.com/camunda-community-hub/community-action-maven-release/releases/tag/v1.

Using @latest does work: https://github.com/camunda-community-hub/spring-zeebe/runs/4596280606?check_suite_focus=true

So in essence it seems to boil down to that we need to set the right tags / overwrite them. So every time we release a new v1.x version, we should delete and recreate the "v1" tag - what do you think?

[celanthe]

Hi @berndruecker! Yes, I think this is the ideal path forward until we release v2.0 of the action. I will make the changes needed to move the major version tag for v1.0 to point to the Git ref of the current release. :)

[celanthe]

Hi @berndruecker! I have deleted the old v1 tag that pointed to the outdated version of the Action, and moved the major version tag v1 to point to the Git ref of the current release, which is 31b561a. Fingers crossed, this will resolve the issue.

I was wondering if we might want to look into implementing something like https://github.com/nowactions/update-majorver as well, so that we don't have to do this manually in the future? I have an OKR for this quarter that is scoping creation of a unified build process. This is something I can look into possibly implementing. On the other hand, we don't release that many new versions of the Action and that could potentially be overkill. I welcome your thoughts!

If this is confirmed to be fixed with the tag migration, I will happily update the documentation to reflect these changes. :) Thank you kindly for your help and patience in resolving this issue.

[berndruecker]

Works now with v1 🥳

While I am always a big fan of automation I agree that this iht not be worth the effort if we know what we need to do and can make sure we don't forget...

[celanthe]

Perfect, thanks kindly @berndruecker! Once I've got the documentation updated detailing what we learned here, I will close this issue out.