Automate release #480
Automate release #480
Conversation
|
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:
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! |
There was a problem hiding this comment.
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?
I'm willing to enforce commit message formates if that helps make something automate-able.
But what are your thoughts?
.github/workflows/milestone.yml
Outdated
| ver=${ver#v} | ||
| ver=${ver%-*} | ||
| echo "::set-output name=version::$ver" | ||
| sed "s/^\(AC_INIT.*generator\],\)\(.*\)\(,\[flex-help.*\)$/\1[$ver]\3/" $GITHUB_WORKSPACE/configure.ac >> $GITHUB_WORKSPACE/configure.ac.new |
There was a problem hiding this comment.
Since this is running under Ubuntu, we know that sed is GNU sed. why not use sed -i here instead of sed+mv?
There was a problem hiding this comment.
I am but an egg. I forgot you could do that.
.github/workflows/build.yml
Outdated
| jobs: | ||
| build: | ||
|
|
||
| runs-on: ubuntu-18.04 |
There was a problem hiding this comment.
| runs-on: ubuntu-18.04 | |
| strategy: | |
| fail-fast: false | |
| matrix: | |
| arch: [x64, x86] | |
| os: [ubuntu-18.04, ubuntu-latest] | |
| compiler: [gcc, clang] | |
| runs-on: ${{ matrix.os }} |
I was just browsing through and thought I'd suggest some type of matrix... though not necessarily this one. :)
There was a problem hiding this comment.
Point taken. I'm focusing on the release machinery in this PR but more extensive matrix testing is a good thing. I'd like the matrix test workflow to run early in the integration pipeline so the release workflow can stay streamlined. I'm having to repeat a lot of build code between workflows, though. Ready to learn.
There was a problem hiding this comment.
I'm having to repeat a lot of build code between workflows, though. Ready to learn.
I'm not too great with Actions yet... your yml looks pretty good though, a lot more advanced than I have done.
Of course one way to prevent code repetition in these workflow files is using shell scripts, but I didn't see where you could do that in the use-cases you need (I noted one example below where you could).
One thing that might help trim a few lines is to combine some of the name/run lines. You don't need a "name" for every "run". Example:
- run: ./autogen
- run: ./configure
- run: make
- run: make check
- run: make distcheck
or
- run: |
./autogen
./configure
make
make check
make distcheck
Or because that sequence of commands is used in build.yml and milestones.yml, put them in a shell script.
- run: sh .github/scripts/build.sh
There was a problem hiding this comment.
Oh, you could probably actually remove the make check since make distcheck does that automatically.
Also, I find that using make V=1 can be handy sometimes
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.
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.
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. |
|
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
<#480 (comment)>, 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. |
…lper.
Trigger when milestones are closed.
Take the version name from the Milestone title.
Create a release, too.
Mightyjo
force-pushed
the
automate-release
branch
from
80d60a5
to
cbaa930
Compare
|
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.
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.
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 |
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. |
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. 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? |
Totally supportable. Just looks like a second subordinate GPG key in this process.
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.
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. |
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? |
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. |
Thank you. Just the tar ball that make distcheck would build. Make any assumptions you need to make it easier to do. |
|
Quick update to say I'm almost there. This has been interesting. Pretty much every API changed since I wrote the milestone version. You can see how it's working on my fork. The tarballs are attached to the action runs for Nightly. They persist for 90 days right now. I plan to attach them to tags. Still figuring out that API and the needed token permissions. |
In my personal opinion, I wouldn't do that. Nightly builds that create tags or even GitHub Releases just spam everyone watching them in some way (e.g. via notifications) |
|
Fair point. I was thinking about how to announce successful nightlies and keep their links together. Ideas welcome! |
|
I'd suggest making a nightly release and replacing files upon successive nightly releases. (There is an action that does that if you wanna go that route.) |
Sounds good and avoids spam :D Alternatively, it could be a way to create some new |
|
That took longer than I expected. Nightly builds are working in my fork and uploading to a release/tag called "nightlies". Please take a look at my nightly-build branch, currently my default, over the next couple of days to see the files build up. I'm uploading both "Source" and distro tarballs right now. I'll probably drop the "source" stuff since it's just duplicating what's in git at the named commit hash. I have a bit more work planned to remove duplicated script chunks from the three workflow files. I'll also refactor/squash a sequence of commits from tonight in which I was chasing my tail over a token permissions SNAFU. |
|
What is needed to advance this topic and get it finally merged? A rebase? More feedback? Some reviews? |
|
@gruenich the issues are time and money. I'm working on them both. |
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).