Merging into the same branch should not abort the workflow when disabled

jagiella commented 1 year ago

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

I get an error when releasing on the default branch (main), eventhough the documentation suggests that the allowSameBranchMerge option is false by default.

[3:03:38 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Process aborted due to an error while backmerging a branch.
[3:03:38 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Error: Branch for back-merge is the same as the branch which includes the release. Aborting back-merge workflow. 
    at performBackmergeIntoBranch (file:///builds/mlcv/common/libmlcv/node_modules/@saithodev/semantic-release-backmerge/dist/perform-backmerge.js:10:15)
    at performBackmerge (file:///builds/mlcv/common/libmlcv/node_modules/@saithodev/semantic-release-backmerge/dist/perform-backmerge.js:99:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async success (file:///builds/mlcv/common/libmlcv/node_modules/@saithodev/semantic-release-backmerge/dist/index.js:52:5)
    at async validator (file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/lib/plugins/normalize.js:36:24)
    at async file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
    at async file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/lib/plugins/pipeline.js:31:3
    at async pluginsConfigAccumulator.<computed> [as success] (file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/lib/plugins/index.js:87:11)
    at async run (file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/index.js:[215](https://serv26.art.site/mlcv/common/libmlcv/-/jobs/27312#L215):3)
    at async Module.default (file:///builds/mlcv/common/libmlcv/node_modules/semantic-release/index.js:275:22)
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1

Expected Behavior

should always merge back to main except the release happens on main.

Edit: Or at least that should not lead to an java error, making the pipeline job fail ;-)

Steps To Reproduce

The configuration is

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    ["@saithodev/semantic-release-backmerge", {
      "backmergeBranches": [
        "main", 
        {"from": "production", "to": "pre-production"}],
      "mergeMode": "ours"
    }],
  ],
  "branches": [
    {name: "main",           prerelease: "dev"},
    {name: "pre-production", prerelease: "rc"},
    {name: "production",     prerelease: false}
  ]
}

Environment

- **semantic-release/semantic-release** version: 20.1.1
- **@saithodev/semantic-release-backmerge** version: latest

Anything else?

No response

saitho commented 1 year ago

What's the branch you're releasing from?

jagiella commented 1 year ago

The error occured after pushing a commit (adding the backmerge config to .releaserc.json) to the main branch.

We follow the gitlab flow branching scheme:

main (=default): pre-release branch (development)
pre-production: pre-release branch (testing / staging)
production: release branch

saitho commented 1 year ago

I think the behaviour is correct, with allowSameBranchMerge=false. You're releasing from main branch and specified it should be backmerged to main. Usually there is no point to backmerge into the same branch, as the commits are the same. Hence the error message.

Going by your expected behaviour, you want it to merge into main when the release was done from production or pre-production branch. I'd suggest defining specific targets for those branches, instead of just the branch main which does not consider the branch the command runs from. Like that:

 "backmergeBranches": [
-    "main", 
+    {"from": "pre-production", "to": "main"}, 
+    {"from": "production", "to": "main"}, 
     {"from": "production", "to": "pre-production"}
 ],

jagiella commented 1 year ago

That is the workaround that I currently use now.

Nevertheless, I disagree on your argumentation. Here is why :smile:

In the documentation it's stated that the default settings are backmergeBranches: ['develop'] and allowSameBranchMerge=false.

i.e. all releases are going to be back-merged into develop
i.e. also (pre-)releases on develop would be merged into develop
i.e. the default config should then always lead to failed pipelines for releasing on develop -> in my opinion not desirable behavior

If I alter the configuration to backmergeBranches: ['develop'] and allowSameBranchMerge=true, then

all releases are going to be back-merged into develop, releases from develop as well -> not a desired behavior neither

Merging back into the same branch should just be ignored completly without any error / pipelines failing.

saitho commented 1 year ago

In the documentation it's stated that the default settings are backmergeBranches: ['development'] and allowSameBranchMerge=false.

The documentation states that backmergeBranches: ['develop'] is the default branch for backmerges. In my world, releases are never done from a unstable branch like develop but from main/master which is stable. I haven't used the "branches" setting from semantic-release before, but I understand you can realize prereleases with that – releases that are per definition unstable. For the problem you described, the "workaround" is the actual solution to the problem.

i.e. the default config should then always lead to failed pipelines for releasing on ~development~ develop -> in my opinion not desirable behavior Merging back into the same branch should just be ignored completly without any error / pipelines failing.

I agree, there is no need to make the pipeline fail.

jagiella commented 1 year ago

The proposed branching configuration works (for main). Nevertheless, when merging/commiting into production / pre-production now I am running into #35, #36, #42. #43.

[4:28:19 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Process aborted due to an error while backmerging a branch.
[4:28:19 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Error: Command failed with exit code 1: git push [https://gitlab-ci-token:[secure]@REPO_URL.git](https://gitlab-ci-token:%5Bsecure%5D@REPO_URL.git) HEAD:main 
To https://REPO_URL.git
 ! [rejected]        HEAD -> main (non-fast-forward)
error: failed to push some refs to 'https://REPO_URL.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
    at makeError (/builds/REPO/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/build/REPO/node_modules/execa/index.js:118:26)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async file:///builds/REPO/node_modules/@saithodev/semantic-release-backmerge/dist/helpers/git.js:16:32
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: exit code 1

saitho / semantic-release-backmerge