One-step release action #368
Conversation
08c69c5 to
14ed4d3
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #368 +/- ##
=======================================
Coverage 96.04% 96.04%
=======================================
Files 31 31
Lines 4219 4219
Branches 645 645
=======================================
Hits 4052 4052
Misses 95 95
Partials 72 72 ☔ View full report in Codecov by Sentry. |
be924f4 to
60365cf
Compare
|
https://github.com/pace-neutrons/Euphonic/actions/runs/13246775974 |
|
All looks pretty convincing amd release page has appeared. GH is also showing some scary deployment rocket logos, but as far as I can tell nothing actually went to PyPi. I guess the next step is to uncomment the PyPI lines, merge this, and try it for real 🫣 |
|
Taking a closer look at the This is currently designed to fire off if you
But it didn't fire off when I tested the new release.yml action. Manual dispatch would not be especially useful:
There is also a question around how the "push" trigger interacts with release branches. After releasing we would typically merge the release branch to master and this could trigger another landing page build for the already-released version. This will update the "latest" page (as opposed to a specific version) found at https://pace-neutrons.github.io/Euphonic/. So that's probably working as intended, actually? |
eca993b to
74093de
Compare
|
Ok, that last run successfully deployed a 1.4.1rc landing page (which I had better clean up...) but did not create a corresponding "latest" page, so "latest" still shows up as the previous release. Perhaps for now we will leave that be and rely on the eventual merge to I think everything is done here; I'll clean up the garbage releases and uncomment the PyPI push lines. |
Now this script can be used in the following ways: - without "--replace" argument the new CHANGELOG is printed to stdout - If there is Unreleased content and the requested tag already exists right after Unreleased, we assume that a failed release is being fixed. Content from Unreleased is moved into that section and appended to what is already there. - If the tags match but there are no Unreleased changelog notes, nothing much should change. (Maybe some line breaks.) This might be the case if we are on a release branch and already manually updated the CHANGELOG. - Otherwise, we create a new release section under Unreleased, move content from Unreleased into that section, and update the "compare" links. While working on the parser I ran into a broken link and some inconsistent spacing in the existing CHANGELOG.rst file.
This could be done in a _slightly_ more modular fashion but would add a bit of complexity as well to pass around the file changes across actions without making multiple commits in the history. The nice thing about this setup is that bump_changelog.py doesn't mind at all if you already sorted out the CHANGELOG by hand, so if there are any difficult/edge cases they can be handled by using a release branch and running the script locally before using the release action.
itertools.batched is from Python 3.12. Not a complete dealbreaker, but makes life simpler as developers are likely running the script from a Euphonic dev environment which is 3.10 with toolz available.
Change of plan: we _do_ need to push the version/tag commit in order to have a sensible multi-job workflow. We do want that multi-job workflow because versioning tweaks should happen on one OS but building/testing needs to be matrixed. But this should generally be done on a release branch, so if the release fails it will be possible to clean up these commits/tags without messing up the master branch history. It seems a good idea to provide standalone build/test actions for debugging. By separating the sdist and wheel builds they can be called in parallel as part of overall release workflow. A couple of details still to work out at this point: - The OS matrix should be moved up to release.yml and passed as an option to build_wheels, so it is possible to troubleshoot one OS at a time. - We may need to store the normalised release tag to environmnent and use in subsequent steps instead of inputs.ref. That way, small formatting changes like adding "v" will be carried forward correctly. https://docs.github.com/en/actions/sharing-automations/reusing-workflows#using-outputs-from-a-reusable-workflow
The workflow visualisation tends to put the "test sdist" step right on top of the dependency line from build-wheels to release. This is quite misleading as it looks like test sdist depends on build-wheels and yet it can start running before build-wheels is done. Perhaps if we swap the jobs they will be stacked in a different order and it will look clearer?
We could streamline things a bit by moving the code directly into release.yml, but for now let's keep options open.
This seems like overkill, we have already been quite careful to create consistent version information. But it wouldn't hurt to have these checks running for an automated release cycle before we consider pruning them.
release.py is complaining that CHANGELOG is out of sync. How can that be?
Release script correctly picked up that the version number was written to changelog without the leading "v": this is inconsistent!
This is a pretty confusing Actions behaviour: the github.event_name is inherited from the calling workflow so create-landing-page thinks it is a workflow_dispatch when called from release.yml
66b28f5 to
699501d
Compare
|
@oerc0122 I think I've run enough sanity checks that it works, but maybe you could have a glance at the overall logic? |
Co-authored-by: Jacob Wilkins <46597752+oerc0122@users.noreply.github.com>
Co-authored-by: Jacob Wilkins <46597752+oerc0122@users.noreply.github.com>
Closes #326
Replaces #364
(Forgot that when branch name contains "release" tests get run twice. Should probably clean that up, but for now just use a different branch name...)