-
-
Notifications
You must be signed in to change notification settings - Fork 278
semantic-release #365
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
semantic-release #365
Conversation
c1686b2
to
9cde8c3
Compare
4d5c757
to
c107c50
Compare
1adf944
to
9a3ef15
Compare
90c471e
to
e20e525
Compare
e20e525
to
daf0c07
Compare
9e8b634
to
d542fca
Compare
7efbf01
to
d84f189
Compare
Thanks, even if you haven't reproduced entirely the doc generation1, I'm pretty confident. I've now set/reset all the temporary values: we should be good to merge. Some last points to ultimately check on your part before the merge:
The merge of this PR should trigger a I let you do the final review ;) Footnotes
|
bc49965
to
9512e62
Compare
9512e62
to
a5e579d
Compare
🎉 This PR is included in version 2.2.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I'm relieved it went smoothly :)
No because I've set up this to prevent that: camera-controls/.github/workflows/release.yml Lines 8 to 10 in 5546a53
If you merge both PRs "fast enough"(which I agree is tricky), the last It may be not ideal, and yes we could totally and easily change the release-branch from It basically has a timeout that triggers the merge if no PR has been merged since this timeout. It seems designed for the need of grouping PRs together. It's all new and I have never tried it yet, but may worth a try? What do you think? |
Oh but I'm realising that:
-- from "Managing a merge queue" Github doc so it won't be available for |
So if you prefer, we can prepare a new PR to set the release-branch on It will allow you to merge on |
Just for info, If we look how it works for Therefore, if you look at the releases list, nearly each release is composed of a single PR merge: https://github.com/pmndrs/drei/releases One exception is this v9.56.25 release: composed of 2 PRs I guess it's really a matter of preference here. It would have been cool to test the new "merge-queue" feature, but since it is not available for personal repos, I guess you have to decide on this: release-branch set on Footnotes
|
I have drafted a PR #377 if you want to switch to |
Sorry for the delay, and thank you for taking the time to think about this.
Okay, let me try with the 2 PRs.
good to know that...! that's why. |
As you mentioned, it works for multiple merges. (and no need to write a change log...! 🤩) But now I worry about what if I got a conflict meantime. |
localhost Verdaccio publish
Test the release
.github/workflow
in Actions -- on Github Packages registry (not to conflict with npm registry)Integrate doc generation to the github-action workflow
Once everything is tested, change some values (cf. comments) and delete tests-related files
Verdaccio (local registry)
To test it on your localhost:
semantic-release
branch fromdev
yomotsu:semantic-release
branch:$ git push origin semantic-release # because a remote branch should exist for semantic-release to compare against
contents: write
issues: write
pull-requests: write
Resulting built+published on my local registry Verdaccio:

Resulting release on my fork: https://github.com/abernier/camera-controls/releases/tag/v2.2.2
