-
-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate releases #1688
Comments
Today I factored out a https://github.com/cucumber-actions/create-release-pr/ action which will cut a lot of the boilerplate out of adding a |
The current strategy to mark the commit to be released with a temporary Maybe the pre-release script needs to make a "Draft" Release (and a tag), then we can just publish that Release when we make the actual release. |
We can pull out the sha of the commit being released like this:
That should work even if the |
I've sketched out a repo for a |
We now have a working GitHub Actions release workflow in Preparing a release is still a bit too manual for my liking. Things I'd like to improve:
Now that we're splitting up |
I must say that once it is working, I find the release process pretty smooth. I like it a lot. I see two things we could improve:
|
WDYT? |
What would be the value to use a workflow over a local script? |
The main benefit would be that we don’t have to install the we also wouldn’t have to copy-paste the pre-release script across multiple repos (but we’d still have to enable the action for each repo) |
I have added some TODOs following the comments here: cucumber/cucumber-ruby-core#224 (comment) |
Some feedback after having released First of all, it worked as expected. It was pretty smooth 🤩 In short:
The workflow has been copied from
Also, as the repos have a single implementation, there was a single release workflow with the publication of the ruby gem, then the creation of the release on github. That may not be as simple with repos with multiple languages. As an attempt of factorization, I have created an action to execute the tests, and use that action as part of the test workflow and the release workflow. I don't know how far we could factorize the process. There are some redundancy across the repositories, but I am not sure this is because of duplication. We could maybe create a precheck action, but other jobs are already pretty well factorized into their own dedicated actions. What we have to take care of is: if we tweak the release for a repository, we may have to update it for other repositories as well. Also as @aslakhellesoy pointed out, the RELEASING.md document could be standardized. I am pretty confident with that process. BUT, there is a point we have to be extra careful: the security of the process rely on github settings: the protection of |
@mattwynne @aurelien-reeves can we close this now and have smaller tickets for the remaining projects? |
Tracking continued progress at https://github.com/orgs/cucumber/projects/13 |
Using this issue to bring together the efforts scattered across other repos.
The goal is to have all releases to RubyGems, NPM, Maven etc. made by GitHub Actions workflows. We'll use GitHub Environments to secure the secrets used to publish packages.
publish-rubygem
actionversions
action to read the changelog latest and tagged release versionscreate-release
action. WIP in https://github.com/cucumber-actions/create-releaseget-released-version
action which is superseded by the newversions
action.publish-go
actioncheck-release-commit-is-on-main
action (see hereThe text was updated successfully, but these errors were encountered: