2

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?

  1. 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.

  2. 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.

jonrsharpe
  • 1,311
Jake Lam
  • 159

1 Answers1

3

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.

Graham Lee
  • 506