maxgoedjen
commented
3 months ago WRT the ideas mentioned: the main idea here is to have all of that happen in a visible place (ie, on CI) vs locally – I'm not opposed to this in theory if it's runnable on the CI, although I'd lean towards just leaving as-is until it becomes an issue personally.
Description
This PR updates some of this project's workflows to use newer versions of official reusable actions:
In both cases, the updates should address deprecation notices on the changed workflows.
Future Considerations
There are a few things I opted not to do as part of this PR:
Fixing formatting and indentation in workflow YML files. I ignored this for now as it would introduce a much larger diff and would obscure the meaningful changes.
Migrating from archived actions to maintained replacements. In 2021, GitHub archived two of the actions used by this project:
That's rather bothersome. Both of those actions are generating deprecation warnings and could stop working at some point in the future altogether.
Some ideas:
Transition the "release" workflow to trigger on the creation of a Release rather than on tag creation. This may be done either via the web UI or the CLI (e.g.
gh release create v1.2.3 --generate-notes). Creating a Release will generate a tag and I think much of the existing "release" workflow can remain the same. That is a process change, though.Replace the use of actions/upload-release-asset with an equivalent using the GitHub CLI. The CLI is available on GitHub-provided runners and can use the REST API to push an asset (documentation). I haven't tried this myself, but the pieces should all be there.
I'd be happy to PR either or both of the above, further document them in an Issue, and/or put together a quick demo repo of the process.