-
Notifications
You must be signed in to change notification settings - Fork 113
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
Update of GitHub Actions Workflows #205
Conversation
d253aa5
to
2d85ea9
Compare
Thanks, the ability to release manually in the shorter term is perfect, and stale issue automation is also something I've been meaning to get working for quite some time! |
@pplancq - apologies, from reading your comments and looking at the code in this PR and your 'dev-tools' repo, I'm still not quite clear on how the manual release process works. Is it now looking for a specific commit message pattern, like 'Release v4.0.10'? |
Apologies, I forgot to explain how it works . To paraphrase Apple, "it's magic" 😊. To put it simply, all you have to do is write your commits correctly, respecting the conventional commit. Then semantic-release will retrieve the last git tag, then the commits since the last tag, and depending on the type of commit, it will determine the new version as follows:
I've seen that you've added the 4.0.10 tag, so normally if you run the workflow on the basis of the commits, it should generate version 4.0.11. I hope this answers your questions |
Also, if you restart the release workflow just after making a release, semantic-release will see that no new commit has been made since the last tag, so it won't do anything. |
Ah, run the workflow manually. Based on your statements above, I was thinking it was based on commits with some magic code somewhere. 😆 |
My apologies for the confusion. I asked for the 4.0.10 tag to be added so that semantic-release could take over the numbering from there. Without this tag, there is a risk of conflict with npm because the last tag was version 4.0.1 and semantic-release can generate a version 4.0.4. By using this 4.0.10 tag, semantic-release can generate version 4.0.11, 4.1.0, or even 5.0.0 when the release workflow is launched. The version number is determined solely by the type of commit (feat, fix, etc.). I hope this explanation will reassure you about how it works. I've made releasing a new version extremely simple for you, with the aim of saving you as much time as possible 😀 |
🎉 This PR is included in version 4.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This PR introduces several updates to our workflows for GitHub shares.
Release workflow update: The release workflow has been updated to incorporate
semantic-release
. This workflow is manually triggered, allowing you to release a new version when you feel the master branch is stable and ready for release. The process is then fully automated, handling the generation of the new version number, creation of the changelog, updating ofpackage.json
, npm publishing, git tagging, and even publishing to GitHub.⚠ However, for this to work correctly, it is imperative to add the
v4.0.10
tag to commit 475edb427a3e8c708719cb3dd6b6d5aac3b5012f.Build workflow modification: The build workflow has been modified so that
commitlint
only runs once.Stale Action Update: The stale action has been updated to automatically close issues and/or PRs that are no longer updated.
I've made this change to make maintenance easier for you, and I hope you'll find it useful.
We welcome your comments and feedback.
fix #195