Bot cannot receive pipeline status with no-ff-merge

[afemu]

Hi, we are trying to set up marge bot for our gitlab instance via CI with https and a scheduled pipeline. The bot is running so far, recognizes the MRs its assigned to, but fails to recognize the associated pipeline. I assume that since we use no-fast-forward-merge, the bot compares the SHA of the altered commit with the SHA of the merge commit. This causes the following output:

2022-06-16 16:17:10,705 WARNING No pipeline listed for 97d046343745b1a1d15e1268ada230930919d1cd on branch feature/some-feature
2022-06-16 16:17:10,705 WARNING Suspicious CI status: None

Did I misunderstand something or does the bot only work with fast-forward merges? We are currently forced to use merge because we maintain multiple branches that cannot be kept in sync via rebase due to hotfixes/releases, etc. However, our development branch should be using rebase.

Can anybody point me to the right direction?

Thanks in advance!

[vassilisimon]

Could anyone help? @nithyashree675 @snim2 @commodis @qqshfox @JaimeLennox

[commodis]

We use MargeBot with only-ff, but that should not matter in my opinion. Do you give Marge enough permission to read the status of the CI through the API?

[afemu]

Yes, the bot has enough permissions. With debug-flag enabled we can see that it correctly fetches all the pipelines via api but fails to detect the one that is actually referring to the MR:

2022-06-16 16:17:00,436 DEBUG https://gitlab.someinstance.com "GET /api/v4/projects/1111/merge_requests/1132/pipelines HTTP/1.1" 200 None
2022-06-16 16:17:00,438 DEBUG RESPONSE CODE: 200
2022-06-16 16:17:00,438 DEBUG RESPONSE BODY: b'[
{"id":1564250,"iid":6986,"project_id":1111,"sha":"31d10da42bfa3af582ac6a301bf87b438f04e9c7","ref":"refs/merge-requests/1132/merge","status":"success","source":"merge_request_event","created_at":"2022-06-16T15:50:39.238Z","updated_at":"2022-06-16T16:13:19.311Z","web_url":"https://gitlab.someinstance.com/some-project/-/pipelines/1564250"},
{"id":1564113,"iid":6977,"project_id":1111,"sha":"5d4e00516137f7150bd7d3c86183e4c59d4fab50","ref":"refs/merge-requests/1132/merge","status":"success","source":"merge_request_event","created_at":"2022-06-16T14:17:19.893Z","updated_at":"2022-06-16T15:34:07.073Z","web_url":"https://gitlab.someinstance.com/some-project/-/pipelines/1564113"},
{"id":1563341,"iid":6962,"project_id":1111,"sha":"6d13bd093b3aced36e5f10107b16da9fcb70e4b7","ref":"refs/merge-requests/1132/merge","status":"success","source":"merge_request_event","created_at":"2022-06-16T07:15:57.924Z","updated_at":"2022-06-16T07:39:26.589Z","web_url":"https://gitlab.someinstance.com/some-project/-/pipelines/1563341"},
{"id":1555533,"iid":6823,"project_id":1111,"sha":"4366d066f2cfa10685574205fc9f8aaf275c9ae9","ref":"refs/merge-requests/1132/merge","status":"success","source":"merge_request_event","created_at":"2022-06-14T06:34:02.583Z","updated_at":"2022-06-14T06:56:00.752Z","web_url":"https://gitlab.someinstance.com/some-project/-/pipelines/1555533"}
]'
2022-06-16 16:17:00,438 WARNING No pipeline listed for 97d046343759b1a1d15e1268ada230930919d1cd on branch feature/some-feature
2022-06-16 16:17:00,438 WARNING Suspicious CI status: None

In this particular case the correct pipeline would be the one with id 1564250. The latest commit on this branch was the one from marge-bot with sha 31d10da42bfa3af582ac6a301bf87b438f04e9c7 but as stated in the logs the bot looks out for 97d046343759b1a1d15e1268ada230930919d1cd which is the last commit the developer added on the branch before assigning it to marge-bot.

[commodis]

Reading the README suggests, that marge-bot is programmed to handle semi-linear (rebase) and fast-forward merges.

Maybe the CLI option --use-merge-strategy can help?

Use git merge instead of git rebase to update the source branch (EXPERIMENTAL) If you need to use a strict no-rebase workflow (in most cases you don't want this, even if you configured gitlab to use merge requests to use merge commits on the target branch (the default).) [env var: MARGE_USE_MERGE_STRATEGY] (default: False)

I am not sure if the description really matches your use case, but maybe you can evaluate that.

[afemu]

Mh, but this means the bot will MERGE the target into the source before merging it back into the target. Thats absolutely not what we want. We want to keep rebase strategie on the source branch. Or do I understand this wrong?

[commodis]

Maybe you need two different marge-bots?

1. handles the development branch via usual rebase
2. handles the product-line branches

[afemu]

Unfortunately this won't really help us. Even with two different marge-bots we would need to change our merge strategy to rebase instead of using semi-linear history. We dont want this. Also handling the MRs for releases / hot-fixes are not an issue at the moment which makes a second marge-bot unnecessary. :/

[afemu]

We now changed our branching strategy to be able to make use of rebase / semi-linear history but are still not able to get the marge bot running. The issue is the same: The bot is unable to detect the correct pipeline :/ Any other tips or hints?

E: We found the issue. The cause was using "Merged result pipelines" in the repository settings which (for obvious reasons) differs in its commit hash. Ill close this request. Thanks for the help.

[anuprama]

HI @afemu @nithyashree675 @snim2 @commodis @qqshfox @JaimeLennox. we still have the issue and use semi-linear without the "Merged result pipeline" option specifically on batched merge jobs. Any help

[commodis]

Just fork it and fix it yourself - this repository is sadly dead. The last release was over 1.5 years ago and there is no official statement from smarkets or transferred stewardship. The new project at https://gitlab.com/marge-org/marge-bot did sadly not make it to a manual release since its creation.