Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
jagiella opened this issue Mar 1, 2023 · 6 comments
Open
1 task done
Labels
bug Something isn't working

Comments

@jagiella
Copy link

jagiella commented Mar 1, 2023

Is there an existing issue for this?

  • 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:38PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Process aborted due to an error while backmerging a branch.
[3:03:38PM] [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

@jagiella jagiella added the bug Something isn't working label Mar 1, 2023
@saitho
Copy link
Owner

saitho commented Mar 2, 2023

What's the branch you're releasing from?

@jagiella
Copy link
Author

jagiella commented Mar 2, 2023

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
Copy link
Owner

saitho commented Mar 2, 2023

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
Copy link
Author

jagiella commented Mar 2, 2023

That is the workaround that I currently use now.

Nevertheless, I disagree on your argumentation. Here is why 😄

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
Copy link
Owner

saitho commented Mar 2, 2023

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.

@saitho saitho changed the title ERROR: Branch for back-merge is the same as the branch which includes the release Merging into the same branch should not abort the workflow when disabled Mar 2, 2023
@jagiella
Copy link
Author

jagiella commented Mar 3, 2023

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:19PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✘  Process aborted due to an error while backmerging a branch.
[4:28:19PM] [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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants