I'm using semantic-release
to auto find out the next version based on the git commit. It's working fine with creating new version, upload to npm and create new git tag. And semantic-release
is executed whenever code is merged to master.
However, in Node.js or front-end project, usually we have a file named package.json
. In this file, there is also a version number. My problem is that the version in package.json
is not updated, which may conflicts with the latest version number on npm. This is said to be done using semantic-relase/git
plugin, however, I'm still confused.
So I wonder what is the best practice?
-
After code is merged to master, run
semantic-release/git
to push a version update commit. However, GitLab stopped me because master is a protected branch and it forbids all direct pushes. I also think that it's not right to direct push. -
When merged to master, run
semantic-release
to find out next version. Then checkout another branch (maybe called feat_version), update the version and push to feat_version branch, then trigger merge request to master (without approval need). However, this method is a bit complicated and I'm not sure if it can be done in GitLab CI/CD pipeline.
Best Answer
My preference is for, and experience is with, your first option. Have the CD pipeline filter out "version bump" commits (usually based on the identity of the committing user). Really the second option is only working around the fact that you don't allow the version-bump bot to commit directly to main, and introduces irrelevant branches and PRs.
I find it a little weird when working in this way, that you get a version x.y.z, then a commit with new behaviour but the same version x.y.z, then the commit that bumps the version to (probably) x.y.z+1. The solution for that is your option 3 ;), apply the semantic release bump and the associated changes as an atomic rebase on top of main.