README.md

Let's start by finding the latest valid release as a control sample:

• Last successful release is 0.2.1
• From the list of "cd" action workflows, it's the build #34 that did the last successful release.
  • 0.2.1 is the determined version as per https://github.com/jenkinsci/conventional-commits-plugin/runs/3026706219?check_suite_focus=true#step:7:1
  • The "Release" step was triggered and ran successfully: https://github.com/jenkinsci/conventional-commits-plugin/runs/3026706219?check_suite_focus=true#step:10:1
  • Date and time are in phase with Artifactory: 2021-07-09 around ~07:30 UTC (https://repo.jenkins-ci.org/releases/io/jenkins/plugins/conventional-commits/0.2.1/)

Let's find when the release 0.3.0 went wrong:

• The next "cd" release workflow run is the build #35
  • The version is correctly set to 0.3.0 as expected as per https://github.com/jenkinsci/conventional-commits-plugin/runs/3033368549?check_suite_focus=true#step:8:1
  • The logs indicates an HTTP/403 Forbidden response when trying to deploy the artefacts of the release 0.3.0 during the "Release" step: https://github.com/jenkinsci/conventional-commits-plugin/runs/3033368549?check_suite_focus=true#step:11:152

There could be 2 reasons for the HTTP/403:

• Either the credentials were rejected during the authentication (credentials changed, authentication server down, etc.),
• OR the artefacts were already exsiting at the time of the "Release" step so the artifactory defined policy is to reject the request with.. HTTP/403.

=> As the credentials have not been changed and there was no incident known at this time on jfrog, let's check the second option.

Why would we have already existing artifacts for the release 0.3.0?

• Someone did the release manually => no way, as the credentials used are the one from the automated system as per @olblak's checks.
• Another build already uploaded the artifacts

=> If we check the "timestamps":

• The release 0.3.0 and its artefacts had been created on Artifactory around 16:10 UTC and 16:43 UTC for the pom/metadatas (ref. https://repo.jenkins-ci.org/releases/io/jenkins/plugins/conventional-commits/0.3.0/)
• The PR #58 was merged at 16:02 UTC jenkinsci/conventional-commits-plugin#58 (comment)
• All the Jenkins associated builds ran at this time: https://github.com/jenkinsci/conventional-commits-plugin/runs/3030737181
• But the "CD" workflow which failed indicate that it ran around 23:14 UTC (ref. https://github.com/jenkinsci/conventional-commits-plugin/runs/3033368549#step:11:149)

It sounds like that the cd workflow was able to upload the release around 16:xx UTC but somehow was re-triggered (or run) only at 23:xx UTC. => this hypothesis should be verified (by fetching the GitHub API for all the workflow run associated to this workflow AND this commit and cross-reference: I feel like GitHub UI is not showing everything). It would explain the behavior (assuming something went wrong and the job failed right after the upload) and is plausbible as "workflow_dispatch" is used in the workflow trigger event for cd.

Remediations:

• It sounds like that if we ensure that there is a tag 0.3.0 created to the commit https://github.com/jenkinsci/conventional-commits-plugin/commit/dd8604eb36cbf58bec9d1742c001ece719982bbb
• If the tag 0.3.0 is correctly done, then the GitHub release 0.3.0 can manually created and should point to this tag. Then it should be filled manually by cross-referencing the content of the "next" release and the commits sinces 0.2.1 (not a lot)
• Then, you can re-run the draft releaser build to ensure that the "next" GitHub release is updated (or update it manually by removing items from 0.3.0)
• Finally, you should be able to trigger the next release