Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci(github): enable manual publishing of custom git tags via input args #3571

Conversation

petermetz
Copy link
Contributor

The all-nodejs-packages-publish.yaml workflow now has an input parameter
where one can specify an arbitrary release git tag (such as v2.0.0-rc.5)
to be the one to be published.

This will help us in scenarios where the release automation script failed to
run on GitHub and we have no way of publishing the given release manually
from a local machine (since we do not have access to the npm/ghcr) tokens
of the foundation (which is good security posture that we are happy to have)

In the scenario described above, in the future this will (should) allow us
to fix bugs in the release automation script in commits that come after
the failed release and then manually trigger the updated (now functional)
publish job for the older release version.

This will (hopefully) grant us the ability to ensure that releases are not
missing from the registries despite sometimes the automation breaking down.

Signed-off-by: Peter Somogyvari peter.somogyvari@accenture.com

Pull Request Requirements

  • Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
  • Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
  • Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

  • Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
  • Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

The `all-nodejs-packages-publish.yaml` workflow now has an input parameter
where one can specify an arbitrary release git tag (such as v2.0.0-rc.5)
to be the one to be published.

This will help us in scenarios where the release automation script failed to
run on GitHub and we have no way of publishing the given release manually
from a local machine (since we do not have access to the npm/ghcr) tokens
of the foundation (which is good security posture that we are happy to have)

In the scenario described above, in the future this will (should) allow us
to fix bugs in the release automation script in commits that come **after**
the failed release and then manually trigger the updated (now functional)
publish job for the older release version.

This will (hopefully) grant us the ability to ensure that releases are not
missing from the registries despite sometimes the automation breaking down.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
@petermetz petermetz force-pushed the ci-github-fix-nodejs-publish-workflow-ghcr-auth branch from e1c2512 to 6dec41d Compare October 3, 2024 22:57
@petermetz petermetz merged commit c331a63 into hyperledger-cacti:main Oct 4, 2024
147 of 148 checks passed
@petermetz petermetz deleted the ci-github-fix-nodejs-publish-workflow-ghcr-auth branch October 4, 2024 01:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants