1

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.

7
  • Protected branches are a GitLab feature, and in no way fundamental to Git.
    – l0b0
    Dec 11 '20 at 9:06
  • 1
    Why does the committed package.json file have to reflect the published version number? Why not follow the policy that only actually published packages (that you retrieve from npm) have a published version number and everything else (even if you were to retrieve the same commit from git) has the version "unofficial local build"? Dec 11 '20 at 10:56
  • @BartvanIngenSchenau what is that policy? Shouldn't the version number in package.json should be consistent with its npm version ? You dont want to pull a package from npm stating version v1.1.0 but in its code package.json still v1.0.0 right ?
    – Jake Lam
    Dec 11 '20 at 14:48
  • @l0b0 good point, thats why I want to look for a solution that can meet the gitlab protected branches philosophy
    – Jake Lam
    Dec 11 '20 at 14:50
  • @JakeLam, what I understood from the FAQ of semantic-release, the package that gets uploaded to npm contains a package.json file with the correct version number. It is only the file in the git repository that doesn't reflect that version number that was derived from the tag. Dec 11 '20 at 15:07
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.

2
  • thanks for your input, so i guess its ok to do a direct version bump to master
    – Jake Lam
    Dec 14 '20 at 2:47
  • @jake yes, in my opinion. Master is “protected” in that you don’t want people pushing unreviewed changes, but your version bump script is neither a person nor making a change that goes through code review.
    – Graham Lee
    Dec 14 '20 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.