Properly implement version bump workflow #15
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 5 5
Lines 386 386
=========================================
Hits 386 386 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
This does what it says on the tin, and seems useful, so approved. The rest is old man rambling.
I'm not sure how much having this in a github action will help in the end (taking the perspective of using this also in the other repos). For example, I'd like a change log somewhere in the repository, and it would still be necessary to manually add the version number to the change log. There might be other places such as installation instructions where the version number might be included. And then also manually updating the version in pyproject.toml doesn't seem to be much of a hassle.
Note that I don't like the changelog to be in version.py, but I think it should be somewhere. And ~every PR should add a line to that changelog, and then when we release, we put the version number in the changelog. Like you did in AstarVienna/ScopeSim#297. But maybe it is not necessary at all to have a change log in the repo itself?
In the long run, I think I might prefer to not have the version number in pyproject.toml at all. That is, have the version number only in the tag, and copy the version number from there when building the package. Installing from a git (dirty) commit that does not have a tag, should get a version number that includes the git commit hash. That is how astropy does it I believe. But I'm not sure what the best approach is, and you are actually doing the work in improving the workflow, so I'm going along.
Anyway, this PR does seem to be a strict improvement. And maybe we can enhance it to also do those other changes that need to accompany a version bump (like putting the version in the changelog). So lets merge this.
This was copied in from an example using manual dispatch only. In that case, the only difference is appearently that it converts bools to strings. But for the workflow to also function when called with parameters, the github.event must not be there. Which then also means bools are bools.
|
Pushed one more small modification, see detailed commit msg. Does not alter behavior, so I'll merge... |
This is a continuation of #14, to fully implement the version bumper GitHub actions workflow.
The workflow can be manually trigger or requested by another workflow and takes one required parameter (the bump rule, or level) and also has an option to perform a dry run, not actually making any modifications. If run without the dry-run option (the normal default), the workflow will commit and push the modifications to the branch it was run from. The commit is officially done by the GitHub Actions Bot. This has the advantage that we don't need a PR to e.g. increment to the next dev version after a release. In the future, this might actually become part of the release workflow, to make sure we're immediately back to a dev version afterwards.
As with the release workflow, this will ultimately become part of the DevOps repo, once it has been proven here.