v4.0.0

v4.0.0 (Major Release)

Status: Released

This is a new major release of the github-actions package. It has the potential to introduce breaking changes that may require a large amount of refactoring. Please read the below description of changes and migration notes for more information.

Description of Changes

• Removes the old npm-ci, npm-publish, and update-dependencies composite actions.
  • These have been replaced with the new equivalent reusable workflows. npm-ci and npm-publish in particular have been replaced with their PNPM alternatives, pnpm-ci and npm-registry-publish.
• Renames tag-commit workflow to create-github-release and creates a GitHub Release when tagging the latest commit with the most recent package.json version.
  • This allows the release information to be more central in the repository itself, rather than requiring people to dig through docs/features every time to find the note manually.
  • It will try and find the docs in docs/releases/<version-type>/<version-number>.md, where <version-type> is one of major, minor, or patch, and <version-number> is a version number prefixed with v.
• Changes the update-dependencies workflow to:
  • Update my pull request templates
  • Split the commits into per-tool-updates rather than one giant commit updating everything.
• Adds a commit-changes composite action that commits changes automatically for you in an action, and also outputs whether or not changes were detected.

Migration Notes

• Switch from using the npm-ci composite action to the pnpm-ci reusable workflow. Likewise with npm-publish to npm-registry-publish, and update-dependencies keeps its name but is now a reusable workflow.
• Switch from using tag-commit to create-github-release and be aware that it will now also create a release.
• Be aware that update-dependencies will also try to create pull request templates as well as update the dependencies.

Additional Notes

• This might be proof that this repository (along with Infrastructure) is the one that's the most tailored to my workflow and is also the one most likely to break existing usage.
• A lot of this will certainly benefit my repositories a lot, but for others it may be worse. That is completely fine and you are welcome to pin the exact version of the package you want to ensure consistency.
• That said, I think the new commit-changes composite action is a nice one. That is far more context-agnostic and is less likely to break your usage if you use it and keep it updated regularly.
• In general, the mental model I will go with here from now on is that the workflows are more tailored to my specific repositories, whereas the composite actions try and be reusable across any repository, not just mine. Hence why I got rid of the existing ones that I wasn't using before I added commit-changes.