Open jagiella opened 1 year ago
What's the branch you're releasing from?
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 branchI 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"}
],
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
.
develop
develop
would be merged into develop
develop
-> in my opinion not desirable behaviorIf I alter the configuration to backmergeBranches: ['develop']
and allowSameBranchMerge=true
, then
develop
, releases from develop
as well -> not a desired behavior neitherMerging back into the same branch should just be ignored completly without any error / pipelines failing.
In the documentation it's stated that the default settings are
backmergeBranches: ['development']
andallowSameBranchMerge=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.
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
Is there an existing issue for this?
Current Behavior
I get an error when releasing on the default branch (main), eventhough the documentation suggests that the
allowSameBranchMerge
option isfalse
by default.Expected Behavior
should always merge back to
main
except the release happens onmain
.Edit: Or at least that should not lead to an java error, making the pipeline job fail ;-)
Steps To Reproduce
The configuration is
Environment
Anything else?
No response