-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
proposal: ci improvements #349
Comments
I see the advantages of what you propose, but from experience I prefer to have less restrictions on commits, and I prefer changelog.md to be written manually
With current process it takes 5 minutes to make a new release (and it's 95% automated thanks to CI), and you have my full trust to perform them so if you want we can make a call next time i make one :) |
I'm curious about the outcome of this, as if it works well, we could try it. The conventional commits requirements could be limited to the title of the commit when the maintainer does a squash and merge of a PR, or to update the title of the PR? If only this has to be changed, it could be great. Or if it uses labels to do the job it could be easy too. |
I've had great success with it, both with teams I've run and in open source. It produces consistently high quality release notes with pretty much zero effort, you can see an example of this on redigo another open source repo I maintain. As @echoix said you can avoid blocking contributors by the maintainer amending the commit during merge, which is exactly I do on redigo, but this could also be a none failing test to encourage contributors to submit PR's with the correct setup. Having the changelog in repo means extra steps for the committer or maintainer or both. I know I've forgotten and had to go back and revise just about every PR. It also results in commit churn with the info from the commits themselves recorded twice, typically in slightly different ways, especially when you amend details as a fix / feature evolves resulting in busy work when the same info has to be edited in two different places. Another benefit of the automatic approach is that links to PR's and their commits are automatically generated, which is helpful for users if they suspect an issue with a change or even if they want to find out more, all very useful. In the same vain we could also eliminate the duplication of files under Thoughts? |
Forgot to mention the release process for redigo is to create a new tag, no details needed, the github action does everything else from filling in the release notes to building the release, so human effort takes about 10 seconds. |
@stevenh as a part of me has a touch of "marketing", I still prefer manually written changelogs, but as we are in maintenance , the information probably does not need to be manually refactored (and even if it did, it can be done by manually updating the release after) And anyway I'm so happy that you fell from the sky to save the project that I can't refuse you anything 🤣 , so you have my go for :
Please just keep the manual validation (by one of us with environment management) for the release GH Workflow , I find it more secure :) |
Thanks for the vote of confidence @nvuillam appreciate it. I'll look at what currently exists see what's in play and what the best options are for npm repo. I can confirm that once created by the action you can manually edit at any point, so if you want to customise, that's really easy. |
Think the bot is a bit keen |
What do we think about improving the CI so we have to do less work, a few things come to mind:
The text was updated successfully, but these errors were encountered: