Merge failing after affiliation change
Summary
My commits can't be merged after the affiliation change
Steps to reproduce
Create a new commit like eclipse/oniro-core/oniro!342 (merged) with the changed email address (both Author and Signed-off-by) Get review, try to merge -> fail
What is the current bug behavior?
'An error occurred while merging. Try again.'
What is the expected correct behavior?
The merge should succeed
Relevant logs and/or screenshots
eclipse/oniro-core/oniro!342 (merged)
Impact
Blocking my contributions until solved
Activity
added ECA ~16083 labels
mentioned in merge request eclipse/oniro-core/oniro!341 (merged)
assigned to @malowe
added team:webdev label
added statetodo label and removed team:webdev label
mentioned in issue #2051 (closed)
@mrybczyn I took a look at the repository settings for eclipse/oniro-core/oniro and saw that the following setting was enabled:
Check whether the commit author is a GitLab user Restrict commits to existing GitLab users.
This is known to trow the error that you see. I've disabled it. Can you try now to see if you can merge?
-
No, but we might get more information if you push your branch https://gitlab.eclipse.org/mrybczyn/oniro/-/tree/fix/readme under a different name using git CLI.
The git CLI is way more verbose. It should include a link and information if the issue is ECA related. It's not idea but it might help us better understand why this is failing.
-
I just did a test, and realized that our hook will not flag any issues when pushing to a fork.
Total 3 (delta 2), reused 0 (delta 0) remote: Non-Eclipse project repository detected: ECA validation will be skipped. remote: remote: Note that any issues with sign-off or committer access will be flagged upon merging into the main project repository.
We would only get more information if you push your branch to the project repository.
I did notice that your PR is 4 commits behind the target branch. Can you rebase and try merging again? Your commit should be fine. I reviewed your ECA status and everything checks out but I am wondering if the ECA is failing because of an older commit.
If I am correct, rebasing might do the trick.
-
Related to this, I created a feature request aboutt returning more info when a user pushes a branch to their fork before creating an MR: eclipsefdn/it/api/git-eca-rest-api#84 (closed)
We have a little progress today. Not sure what you have enabled, it's now showing an ECA error. It's saying I'm using my personal email which isn't in the commit concerned (verified, both author and sign-off are Linaro's). I've also changed the Commiter email field in the GitLab preferences. No idea where this email comes from now.
You have a secondary email set in your account with a gmail adress: Secondary email: rybczynska@gmail.com Verified And the ECA referred to this one.
You should be able to remove it and test again.
Edited by Sébastien HeurtematteI have no idea where you have the list @heurtemattes . Could you provide guidance ?
I'm not sure this could be it. For now it looks that all my emails should be accepted...
Found it, thanks. Merge train in progress. Not convinced but let's try
Edited by Marta RybczynskaNot this. Failed the same way on ECA on the Gmail account
Edited by Marta Rybczynska-
ok, you have also two other accounts with different username and a gmail adress.
Can we try to delete them? And I'll let @cguindon investigate more on the origin of the issue.
-
@mrybczyn Please ensure that the email address in the commit author field matches with your Eclipse account. That step is important to allow us to link an Eclipse account with an EACA.
We have a little progress today. Not sure what you have enabled, it's now showing an ECA error.
We upgraded Gitlab on Friday. I am wondering if the latest version is now returning more information such as the ECA validation URL when the merge fails.
-
We don't use the additional email address for validation. The way the validation works is that we take the email address from the git author field in the git log for each particular comment and we validate if that email address is used by an Eclipse account, if so, we validate if they have an ECA on file.
@cguindon the complete commit is (git show):
Author: Marta Rybczynska <marta.rybczynska@linaro.org> Date: Wed Oct 12 01:09:52 2022 +0200 README: fix a typo Signed-off-by: Marta Rybczynska <marta.rybczynska@linaro.org> diff --git a/README.md b/README.md index 92f8547..d74da51 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ SPDX-License-Identifier: CC-BY-4.0 # Oniro Project -Welcome to the Oniro\* Project main git reposiotory! Oniro is an Eclipse +Welcome to the Oniro\* Project main git repository! Oniro is an Eclipse Foundation project focused on the development of a distributed open source operating system for consumer devices.I can't see the Gmail address inside. I've done such a simple one to test the transition.
Edited by Marta Rybczynska@cguindon there seems to be a general breakage. People can't push to their branches because if that email in the history, apparently. I asked for reports in this ticket
-
@mrybczyn Rebasing should fix the issue. The ECA tries to only validate new commits.
Can you confirm?
No it doesn't. It seems the error now is launched for any fork including old commits (those with the Gmail address as Commiter). It means that nobody can push any fork. This is critical. @agherzan please confirm
-
Can you provide exact reproducible steps?
I will let @malowe investigate once your post that info.
@agherzan could you provide a command log please? I guess that from my account errors are slightly different
The error in my case was the following:
remote: GitLab: Committer 'rybczynska@gmail.com' is not a member of team To gitlab.eclipse.org:agherzan/oniro.git ! [remote rejected] ag/drop-nitro-ave -> ag/drop-nitro-ave (pre-receive hook declined) error: failed to push some refs to 'git@gitlab.eclipse.org:agherzan/oniro.git'And it was due to #1034 (closed). Once disabling the related configuration, this went through. That being said, this is still a problem because there are no commits with the email reported above in the fork. So I suspect something else is also at play here.
-
@mrybczyn What we are looking for is an exact step we should take to reproduce the problem such as:
- Fork the project
- create a branch
- Make a commit...
If you can provide that and we can reproduce the problem, we might be able to help.
Edited by Christopher Guindon @cguindon this needs to be someone else, I do not have any issue pushing to my fork
-
@cguindon Can you point me to the commit you refer to @cguindon? This is how I got into this:
- Push https://gitlab.eclipse.org/agherzan/oniro/-/tree/ag/drop-nitro-ave to https://gitlab.eclipse.org/agherzan/oniro/
- With that configuration in place it failed with:
! [remote rejected] ag/drop-nitro-ave -> ag/drop-nitro-ave (pre-receive hook declined) error: failed to push some refs to 'git@gitlab.eclipse.org:agherzan/oniro.git' Additionally, are you having this problem with a clean branch or one that you've done work in and pulled changes for? The error you provided above is not one from the EF checks, but from Gitlab itself in one of their security features, which as you mentioned should be disabled. If you get that error now, it could be that it has been somehow reenabled on your fork
-
Sure, here is the full log:
Enumerating objects: 2535, done. Counting objects: 100% (1177/1177), done. Delta compression using up to 12 threads Compressing objects: 100% (780/780), done. Writing objects: 100% (843/843), 141.99 KiB | 5.68 MiB/s, done. Total 843 (delta 497), reused 2 (delta 0) remote: Resolving deltas: 100% (497/497), completed with 191 local objects. remote: GitLab: Committer 'rybczynska@gmail.com' is not a member of team To gitlab.eclipse.org:agherzan/oniro.git ! [remote rejected] ag/drop-nitro-ave -> ag/drop-nitro-ave (pre-receive hook declined) error: failed to push some refs to 'git@gitlab.eclipse.org:agherzan/oniro.git'It is a fork. So the branch I was pushing was a local branch, synced with the parent repository and including new commits on top (classic fork, push and merge setup).
And yes, this is an error generated by GitLab directly but:
- This was disabled before so I suspect something (maybe an upgrade) re-enabled it. I am not the only one affected as this was confirmed by other devs too.
- I'm yet to find the commit it complains about and you managed to identify.
Sorry for the delay, wanted to get you a command that would just work out of the box for checking. The command I'm passing gives you the abbreviated hash, committer, and author emails for all commits added to the current branch relative to the origin/kirkstone branch. If you based your branch on kirkstone, you won't have to change it.
git show -s --format='Commit: %h, Committer: %ce, Author: %ae' HEAD...origin/kirkstone^{commit}While this doesn't fix it, it lets us diagnose the current issue at least. Someone on our team looked into your repos and didn't see the flag rechecked for at least your repos and forks. So it may have something flipped somewhere else
-
The command above shows a diff of commits but, as I said, there is no commit anywhere in the history I could find.
Anyway, here is the output for the branch of question:
Commit: 4c0160e, Committer: stefan.schmidt@huawei.com, Author: stefan.schmidt@huawei.com Commit: b6f7ba8, Committer: marta.rybczynska@linaro.org, Author: marta.rybczynska@linaro.org Commit: 09706a4, Committer: ghassaneb.aattar@huawei.com, Author: ghassaneb.aattar@huawei.comAs you can see, the offending email is not there.
About the configuration in GitLab, I have disabled it in the meanwhile to get myself unblocked so it would/should be disabled now.
I asked for it in that format so I could see both committer and author fields in a concise way to validate the branch. You can see the local stuff but I can't, and I want to be sure before we cross it off! It could be something in your fork was munged by something...there's nothing wrong set in the fork but a rule has reactivated itself even though the UI tells us it's off.
About the configuration in GitLab, I have disabled it in the meanwhile to get myself unblocked so it would/should be disabled now.
So wait, is this still an issue, or is it resolved?
So this is what I got when attempting to recreate:
❯ git push origin HEAD -u Enumerating objects: 42, done. Counting objects: 100% (42/42), done. Delta compression using up to 8 threads Compressing objects: 100% (19/19), done. Writing objects: 100% (30/30), 7.19 KiB | 3.59 MiB/s, done. Total 30 (delta 18), reused 13 (delta 7), pack-reused 0 remote: Non-Eclipse project repository detected: ECA validation will be skipped. remote: remote: Note that any issues with sign off or committer access will be flagged upon merging into the main project repository. remote: remote: To create a merge request for m/1, visit: remote: https://gitlab.eclipse.org/malowe/oniro/-/merge_requests/new?merge_request%5Bsource_branch%5D=m%2F1 remote: To gitlab.eclipse.org:malowe/oniro.git * [new branch] HEAD -> m/1 branch 'm/1' set up to track 'origin/m/1'.Commits using my command:
Commit: cdcd326, Committer: rybczynska@gmail.com, Author: rybczynska@gmail.com Commit: 84f28c1, Committer: rybczynska@gmail.com, Author: martin.lowe@eclipse-foundation.org Commit: e26b8b3, Committer: rybczynska@gmail.com, Author: martin.lowe@eclipse-foundation.org-
Sorry for the late reply - I completely missed this one. I think we are good now. I haven't dug more into it due to lack of time but everything seems to work as expected - also confirmed that this is not an issue anymore with other commiters as part of an Oniro PMC-related discussion. Thanks for your support - closing this issue.
mentioned in issue eclipsefdn/it/api/git-eca-rest-api#84 (closed)
assigned to @heurtemattes
Hi, FYI i sorted it out by using the same email that I used to login (it was set by @webmaster IIRC), it looks like that alt emails are not used by gitlab only main one (that should be also set in commit email).
Hope this help
You're pretty much right on the money!
Alternate emails are only used for things like email notifications from the system. Our plugin doesn't even interact with Gitlab itself for validation, only Git! This is a feature in that it works the same for Github and Gerrit as well, so its the same across the board. This means that the biggest impact for this will be how you setup your local Git instance with the user email. There is the smaller use case of using the Gitlab UI, which (I think) pulls your primary address as the committer and author of commits.
