semantic-release / git

:twisted_rightwards_arrows: semantic-release plugin to commit release assets to the project's git repository
MIT License
299 stars 66 forks source link

Plugin does not generate commit message when assets set to `false` #206

Open bniedermeyer opened 4 years ago

bniedermeyer commented 4 years ago

Under the options section of the readme it notes that you can set the assets option to false "to disable adding files to the release commit." However when setting the value to false, no commit is generated. It would be great to be able to generate the commit message without assets.

Use Case

Currently my team is using Semantic Release to manage the releases of our application. We deploy to three different environments (dev, qa, prod) by using pre-releases and using the format of the tag generated to determine which environment to build the release for (alpha goes to dev, beta to qa, and master to prod). There are two pre-release branches, and one branch for the primary release to production. Each branch releases it's own tag format.

  "branches": [
    {"name": "master"},
    {
      "name": "qa",
      "prerelease": "beta"
    },
    {
      "name": "develop",
      "prerelease": "alpha"
    }
  ]

The general workflow we follow is:

# work enters here
commit merged to develop branch > Semantic Release generates alpha tag > app built and deployed to dev environment > testing happens and approval to promote to qa given

# promoting dev to qa
merge develop to qa branch >Semantic Release generates beta tag > app built and deployed to qa > testing given and approval to promote to prod given

# promoting to prod
merge qa to master branch > Semantic Release generates normal tag > app built and deployed to prodcution

We were having issues with having to constantly do manual merging/conflict resolution due to release artifacts when moving between our non-production environments (develop branch -> qa branch), and so split our configuration into two files that are run depending on which branch is being processed by the pipeline. For commits to our non-production branches/envs (develop, qa) we use the folowing:

  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/npm", {
      "npmPublish": false
    }],
    ["@semantic-release/git", {
      "assets": false,
      "message": "chore(release): ${nextRelease.version}\n\n${nextRelease.notes}"
    }],
    ["@semantic-release/gitlab", {
      "gitlabUrl": "<our gitlab url>",
    }]
  ]

For production (master branch) we use:

  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    ["@semantic-release/npm", {
      "npmPublish": false
    }],
    ["@semantic-release/git", {
      "assets": ["package.json", "package-lock.json", "CHANGELOG.md"],
      "message": "chore(release): ${nextRelease.version}\n\n${nextRelease.notes}"
    }],
    ["@semantic-release/gitlab", {
      "gitlabUrl": "<our gitlab url>",
    }]
  ]

This works great for us because we can see the non-production release notes via the gitlab release view, but formal releases of the application to production are captured in the changelog file. We could also promote to the different environments at the click of a button without manually merging code on our local machines. However, shortly after moving to this setup we started to experience reference already exists errors when pushing changes to non-production branches.

Given that we are not experiencing the issue on our master branch that generates release commits, we've figured the version logged in git notes were tied to the commit message generated by the release and now they're instead tied to the tag. Since we rebase our changes based on the last commit made to the branch when working on new features, those notes are squashed with the rebase and Semantic Release can't find them when determining the version when releasing on pre-release branches, resulting in it trying to generate a tag that already exists and failing.

To fix this we would like to have Semantic Release generate the commit message, but not include assets for the pre-release branches. But, when we configure the @semantic-release/git plugin to not include any assets, it does not generate a commit despite the language in the readme that seems to imply it should.

bniedermeyer commented 4 years ago

Hi @pvdlg, any insights into the above? I'm happy to open this somewhere else if this isn't the best place for this issue. :smile:

bestickley commented 3 years ago

Looks like this line is the issue.

averichev commented 1 year ago

same issue

glaerok commented 1 month ago

same issue(