flex
flex copied to clipboard
westes
Automate release
Migrate the CI workflow to Github Actions. Automate the release workflow based on the Milestone system. Closes #337 Automate artifact signing with detached GPG subkeys in Github repository secrets (not in the repo).
Forgot to mention, you can safely leave out commit 5e21333 if you want. It fixes a file permission oddity that was stopping distcheck on my WSL2 VM's tortured filesystem.
If I'd thought about it, I'd have tested the build without that commit on Github Actions before sending the PR.
This is my next priority. Thank you for submiting this. I'll comb through and make sure it does what we want.
Coolness. There's a bit of setup for the release workflow with the pgp keys and your git secrets. The push and PR workflows are easy though.
@westes wrote:
This is my next priority. Thank you for submiting this. I'll comb through and make sure it does what we want.
That's quite cool, I suggest linking #337 to this PR to auto-close the issue on pull.
Even more cool as #337 was specified as "release is very likely to get done and published once this is available" and it is really hard to follow all the changes since the last release (more than 4 years ago) [and only very few people use a snapshot build - and a new release will also be taken up by the package maintainers].
I've been leaving the linking keyword out of my PR messages. Thanks for getting me to look that up!
it's not just all about the milestones; sometimes patches come in via email or things can get commited directly to master.
How do you anticipate handling those cases?
True enough. Starting with the milestone messages kept the demo manageable. I looked at using git2cl at first but the result seemed too fine-grained for the NEWS file.
I'm willing to enforce commit message formates if that helps make something automate-able.
Some kind of commit message formatting could help. I've been practicing the semantic-release formats on my own work. Their repo has some tools and hooks that can help with adoption and automation.
But what are your thoughts?
I started off trying to summarize the commit log but that got out of hand quickly. At this point I'm imagining the milestones as a release backlog and the NEWS file as a snapshot of the finished board. I should be able to augmenting the milestone issues with some specially-formatted commits within the release window to cover emailed patches and similar cases.
I also preserve any text that's already in NEWS so we could add custom entries to the top before running the release workflow. This was this simplest thing that could possibly work.
Anywho, I expected this would need discussion. I'm all ears.
I think this PR tries to do too much stuff at once and hence is staled. First introducing CI builds at all would be already a major step forward. Release automation could be the next step afterwards.
Flex previously used TravisCI. The first bunch of commits in this PR translate that pipeline to GitHub Actions as much as possible. I can split that chunk out from automated releases if it'll get this moving.
On Fri, Feb 18, 2022, 15:37 Michael Keck @.***> wrote:
I think this PR tries to do too much stuff at once and hence is staled. First introducing CI builds at all would be already a major step forward. Release automation could be the next step afterwards.
— Reply to this email directly, view it on GitHub https://github.com/westes/flex/pull/480#issuecomment-1045148435, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVJXINFYP5JX4MC2WSCDN3U32UZTANCNFSM4Z4LJYSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
I (obviously) can't speak for @westes, but I think this pull request would be easier to grasp/review when the migration of the CI from Travis to GitHub Actions would be split out in an own pull request
Right now, no CI is running at all, since Travis requires regularly to ask for more free credits. Getting CI builds back would be nice
I've split the migration to Github Actions out to PR #523. I'll rebase or replace this PR once that one is dealt with.
Rebased the automated release actions after splitting out the codeQL and distcheck actions. Also switched to 'sed -i' as suggested. (I'll handle matrix builds in the build action a little later on.)
The outstanding question from before was here.
it's not just all about the milestones; sometimes patches come in via email or things can get commited directly to master.
How do you anticipate handling those cases?
My milestone_close.rb preserves the existing contents of the NEWS file, so it's feasible to add one-off messages to the top before starting the release. They'll just end up out of order with respect to the Issues.
We could also do something completely different. I mentioned before that I tried several things before hitting on the idea of using Milestones and Issues as progress markers. The trouble is mostly in getting the commit messages for a new release from the GitHub API in a coherent order. I don't think I found the best solution, but I needed more brains to think about it before iterating down a hole.
I'm willing to enforce commit message formats if that helps make something automate-able.
Yeah, this will help. I'm using loosely using this format. If we did adopt that format, we could use semantic-release workflows to build the NEWS and/or ChangeLog.
There's currently no CI generated tarball, is it?
If not then can we get it first (making the result of passing make distcheck available (and before running the tests just update the version string to contain the commit date, similar as it is done here)?
There's currently no CI generated tarball, is it?
If not then can we get it first (making the result of passing
make distcheckavailable (and before running the tests just update the version string to contain the commit date, similar as it is done here)?
Like unsigned nightlies? That's doable.
I haven't learned to save build products for use by other workflows so I've had to run 'make distcheck' in both the test and release flows. I welcome help on that.
Like unsigned nightlies? That's doable.
Yes, that would be very useful for all the peoples visiting this page and don't know enough about the build system and dependencies - just downloading a nightly distribution tarball always helps a lot. Some people use one key for nightly builds and another for releases, the first used for manual verification, the second also in distributions.
And ideally the same step would be executed and only extended for the milestone closed one - did @westes already decided that this would be the last step before an automated release? [I'm personally a fan of "tagging with a defined name = release"].
Note: I really like automated releases as good as it can be done, but personally think a NEWS entry should consist of user-visible adjustments and deserve entries (from time to time, so it doesn't need to be done all directly before the release) written by a human. All other entries of this workflow seem very good to me.
Maybe the "generate NEWS stub" code could be just committed to the repository and be manually executed as "starter" for a human to check which entries to include in which way if that part is found to be necessary?
Some people use one key for nightly builds and another for releases, the first used for manual verification, the second also in distributions.
Totally supportable. Just looks like a second subordinate GPG key in this process.
And ideally the same step would be executed and only extended for the milestone closed one - did @westes already decided that this would be the last step before an automated release? [I'm personally a fan of "tagging with a defined name = release"].
Yep, it's just a different trigger condition at the top of the script. @westes didn't pick the milestone close as the trigger. I guessed at his release process knowing it's easy to change the condition later.
Note: I really like automated releases as good as it can be done, but personally think a NEWS entry should consist of user-visible adjustments and deserve entries (from time to time, so it doesn't need to be done all directly before the release) written by a human. All other entries of this workflow seem very good to me.
Maybe the "generate NEWS stub" code could be just committed to the repository and be manually executed as "starter" for a human to check which entries to include in which way if that part is found to be necessary?
Same. Maybe the automated part should go in the ChangeLog? It's really hard to write/maintain two-part workflows, do I'm reluctant to include commit-pause-resume patterns to get human input. Anywhere we can pull the input from a ready made database is great. Places like the issues and milestone databases seemed perfect.
@Croydon just re-asking for a review, because it was missing after the split of the merged CI actions.
@Croydon just re-asking for a review, because it was missing after the split of the merged CI actions.
I'm not entirely sure why you ask me for a review. I don't have any repository rights here or something like that. So my opinion here is just as relevant or irrelevant as that of any other random person here.
But if you ask me, I'm wondering if the amount of automatization is worth the complexity. IMHO adjusting version numbers in the code, writing the changelog and stuff like closing milestones could happen manually, then you add a new git tag for the new version and the CI is creating a GitHub release, the official release downloads and uploads them to the GitHub release (and other targets if desired).
It would still automate the actual publishing part, but no complex magic how useful changelogs can be auto-generated and what changes need to be automatically created and pushed to git.
@Croydon fair points about complexity.
I demoed everything I could find a way to automate. I don't expect us to keep it all. For example, I'm satisfied that the ChangeLog and the NEWS file serve different purposes. I can automate collection of the ChangeLog, but writing a good NEWS update is a whole research problem (or we could get a Large Language Model to do it).
Amusingly, if we start producing nightly builds it will be less complicated to update the version numbers because the automatic parts will only touch a date or hashcode at the very end. More thoughts later.
@westes What do you think? What steps needs automation and what better remain manual? I am very egoistic, as I want to see this pull request reviewed and merged in any form as soon as possible. Fingers crossed that we get a flex release in a not too distant future. :heart_decoration:
Amusingly, if we start producing nightly builds it will be less complicated to update the version numbers because the automatic parts will only touch a date or hashcode at the very end. More thoughts later.
Could you submit a pr for nightly builds then? It would be particularly helpful since we've had a number of recent changes and clearly a release is in the offing.
Amusingly, if we start producing nightly builds it will be less complicated to update the version numbers because the automatic parts will only touch a date or hashcode at the very end. More thoughts later.
Could you submit a pr for nightly builds then? It would be particularly helpful since we've had a number of recent changes and clearly a release is in the offing.
Yeah, I'll give it a shot.
Yeah, I'll give it a shot.
Thank you. Just the tar ball that make distcheck would build. Make any assumptions you need to make it easier to do.