Github workflow improvements
matthijskooijman opened this issue · comments
While preparing for the 3.0.3 release, I encounted some things in the github workflow that could be improved:
- Fix warning in workflow run: The following actions uses node12 which is deprecated and will be forced to run on node16: actions/checkout@v2, actions/setup-python@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/
- Use --install-deps-from=flathub in the github workflow, so that no longer needs to hardcode the gnome version to be used (also listed in #743).
- Release automation: Reset tree for development by automatically adding NEWS.md header and resetting
VERSION
file. - Release automation: Automatically create github release, with the NEWS.md content for the release and flatpak build included.
- Prevent duplicate push and pull_request workflow runs.
About the last point, there is currently a push
and pull_request
trigger for the testing workflow, so they run for direct pushes to all branches, as well as for pullrequests (including pullrequests from third-party repositories, which do not trigger the push
trigger). This means that for pullrequests that originate in this repo, the workflow runs twice (almost identically).
I looked around and found two potential solutions:
- This uses a conditional to suppress the
pull_request
rule when the source branch is in the same repo: https://github.com/orgs/community/discussions/26940#discussioncomment-6656489 - This implies to use a third-party script that (through the github API, I believe) figures out the pull request that a
push
event pushes to, and if there is one, could suppress thepush
event: https://stackoverflow.com/a/74439898
However, later I realized that both events actually produce slightly different workflow runs: The push
event runs with the original version pushed by the contributor, while the pull_request
event runs on a automatically created temporary merge commit that merges the PR branch into master. That actually seems valuable - for a PR, it is better to test the result of the PR merge, rather than what the contributor pushed by itself, so I would prefer to suppress the extra push
event.
One related observation is that the auto-created merge commit in the pull_request
event is of course checked out, so its git hash is used as part of the git describe
output that is used as the hamster version inside the produced flatpak build (and in its filename). This is suboptimal, since if you want to later figure out what git revision a build was created from, it contains the hash of a git commit that no longer exists anywhere, and can thus also not be traced back to the original sha. We could "fix" this by checking out the original pushed commit instead, but then we no longer test the merged commit. So maybe the github workflow could do some special handling and produce something like Hamster-deadbeef-merged-into-abcdef.flatpak
(and then maybe even include the PR number while we're at it). I'm not sure if we should also do something similar to the version number inside the hamster build (which would require changes to src/hamster/version.py
or wscript
, since those now prefer the git version if it is available).