ci(release): add release workflow and versioning script #18
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add
.github/workflows/release.yml
to automate releases. The workflow is triggered when a branch matching semantic version format and prefixed withv
(e.g.v0.1.1
) is pushed. The steps happen automatically for the most part (italics), with maintainer action (bold) only needed to trigger the process and then review/greenlight each stagemain
main
(not squash/rebase, to preserve history)develop
branch frommain
to reset for next development phase, incrementing minor version number and resetting patch number to 0develop
(not squash/rebase)Use
git-cliff
to autogenerate changelog. On the next release this will add aHISTORY.md
cumulative changelog file.Add
scripts/pull_request_prepare.py
which runsblack
on the modflowapi main module. Could alsoisort
but this caused even more merge conflicts, and was not previously done, so disabled for now. Addisort
to thelint
dependency group inpyproject.toml
though.Add
scripts/update_version.py
to update version strings embedded in themodflowapi
module andCITATION.cff
. This is used in the automatic release workflow above and should generally not need to run locally. Example usage:It can also be used to get the current version with
--get
(short-g
)Notes
Merge conflicts & preserving history
On the first automated release, there will likely be merge conflicts to resolve in the PR created on
main
. This is because when releases are squashed intomain
, it diverges fromdevelop
.In the future, releases can merge (not squash) to
main
to avoid this, then merge (again not squash) the development reset PR back intodevelop
. (The cumulative changelog may also need manual correction the first time for the same reason.)Major, minor & patch releases
The workflow here should work for releases of all three levels, with major and minor releases generally expected to branch from
develop
, where the main development efforts occur, and patch (micro) releases branching frommain
for narrow-scoped bug-fixes.PyPI authentication
The
release.yml
workflow does not use twine username/password to authenticate with PyPI during the publish step. Instead it is assumed thatmodflowapi
has been configured in PyPI to use trusted publishing. Repository secrets for twine username/password are not needed.Testing
Full procedure test run (except publishing to PyPI):