Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Remove release branch workflow #7827
Conversation
etimberg
changed the title
This ensures that release notes can be drafted
etimberg
force-pushed the
etimberg:remove-release-branch-workflow
branch
from
8ca82bf
to
2254d09
|
@kurkle I made some good progress on this. I still need to do the upload release artifacts stuff (though I am unsure how many people use this) but there seem to be a few options for it, though I am unsure how to get the release URL from GitHub so that needs investigation. |
I think you could use that: https://github.com/actions/upload-release-asset |
etimberg
changed the title
|
I added in a few more changes. I tested |
|
@kurkle I think this is good to review. I tested the steps locally and I think the docs stuff is all correct (assuming I got the GitHub actions setup correctly) |
| npm ci | ||
| npm install -g json | ||
| json -I -f package.json -e "this.version=\"$GITHUB_REF\"" | ||
| json -I -f package-lock.json -e "this.version=\"$GITHUB_REF\"" |
kurkle
Oct 12, 2020
Collaborator
Should the version change be committed?
I'm a bit torn about the release workflow. This way lets us do a release of any version regardless of the version in the target branch. A tag will be created with the release version number, but if we don't commit the version change, I think the actual package.json in that tag will have the version that was in the released branch at publish time.
etimberg
Oct 12, 2020
Author
Member
I'm torn as well. Having the version in the code is quite nice, but I'm not sure that we'd want to commit again since the tag would be created when the release is created in the UI. Maybe the flow should be very different and we start with a different action.
kurkle
Oct 13, 2020
•
Collaborator
On approach could be a manually triggered workflow:
- Version as input
- tests
- update package.json and commit
- build and pack
- update draft release with asset
- push docs
- publish to npm
- publish the release
anyway, most of the needed steps are here already, I'm ok with committing this and testing it out.
etimberg
Oct 13, 2020
Author
Member
Ok, perfect. I will commit soon and we can figure out how to test. We have some new features, so we can try to get a beta.4 out the door
Motivation
I keep messing up the release process. The merge to the release branch needs to be done exactly correctly, or else subsequent releases require lots of git correction. This aims to present a simplified release process that integrates better with GitHub. Additionally, we've observed a lot of instability in Travis over the past summer. Moving to GitHub actions for the CI will hopefully provide some needed stability and remove the need to re-run the CI.
To Do
--tag nextfor publish when the release is a pre-releaseTesting
I'm not sure off hand what the best way to test this is. Perhaps switch the command to
npm publish --dry-runand try it out with a tag we don't intend to release?I have run the following manual tests already
./scripts/docs-config.sh "master"successfully sets the version to "master"./scripts/docs-config.sh "3.0.0"successfully sets the version to "latest"./scripts/docs-config.sh "3.0.0-beta.3"successfully sets the version to "next"./scripts/deploy-docs.sh "master"successfully commits to "master"./scripts/deploy-docs.sh "3.0.0"successfully commits to "latest"./scripts/deploy-docs.sh "3.0.0-beta.3"successfully commits to "next"./scripts/publish.sh" sets tag correctly based on$GITHUB_REF`