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.
[x] 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.
[x] 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.
[x] Follow the Commit Linting specification. You may refer to this link for more information.
Character Limit
[x] Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
[x] 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.yamlworkflow 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
upstream/mainbranch 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.-sflag when usinggit commitcommand. You may refer to this link for more information.Character Limit
A Must Read for Beginners For rebasing and squashing, here's a must read guide for beginners.