Intermittent error pushing merge commits from upstream committers without CLA

added IT-prioritylow IT-severitylow Infra ~16083 team:webdev labels

assigned to @malowe

added IT-prioritymedium IT-severitynormal labels and removed IT-prioritylow IT-severitylow labels

I'm able to reproduce this by spamming, waiting, then spamming. This is not intended and should have failed. I'll be looking into how to fix this now. This could potentially bypass ECA, which is not ideal

@malowe just to be clear, this is a fork repository so the ECA checker doesn't make much sense. We actually discussed this in detail here (#1034 (closed)) but in the GitLab configuration context. This wasn't an issue until now. We were able to handle forked repos (3rd party components) and pulling upstream on them without any issues. See for example:

eclipse/oniro-core/meta-zephyr!1 (merged) eclipse/oniro-core/meta-clang!1 (merged)

Pulling changes on 3rd party components will very likely fail any ECA checks. As far as I knew, the aim here was to only do ECA checks for project repositories (1st party) leaving the other repositories aside. Isn't that the case anymore? The repositories in question here are not listed as project repositories on https://projects.eclipse.org/projects/oniro.oniro-core.

So I suspect something more changed lately which now forces ECA on repositories that were not supposed to be checked.

That is indeed the case. We've changed the ECA to explicitly support excluded/mirrored groups so that this case is codified among a lot of other under the hood changes. We were just finishing up some testing, as we deployed this late last week and with national holidays only now had a chance to test it fully. We've checked and it looks like we're ready to roll it out.

As a PL you're actually exactly who I need to talk to! To make sure that the mirrors and any of the other misc. stuff doesn't get caught up in sync operations or ECA checks, we've added a way of setting excluded groups in projects for things like mirrors or forks. This would mean making a group that we can target, and then moving the mirror/fork into that group. This will mean that you'll need to update any remote URLs in your local git setups to reflect the new path. I can take care of the administration side of this today so that you guys are impacted as little as possible by this.

What would you want this group to be named? Does mirrors work for you? Do I have your +1 to do this now?

Probably forks is better suited, given sometimes we have our own patches on top of what's in the upstream repositories.

I'll have to think about it a bit because this has a potentially serious impact on all the references these repositories have. And even so, I'm not sure how this works with the existing initiative of supporting subgroups. Was this change announced anywhere? I personally only found out about it today and it is having a blocking impact on our repositories.

The proposed solution was announced on this Epic: &12 (closed)

The plan was shared with the group via #42 (comment 694534)

The second issue is allowing projects to maintain forks within their project namespace. My understanding is we need to disable the ECA on those repo.

In order to do so, I recommend that we start tracking these exceptions in the PMI in order to inform our ECA validation API that we don’t need to enforce the ECA on those particular repos. In this situation, we would need to be explicit about the full url of these repos.

The final implementation does not require the full URL, instead, we decided to capture the namespace/group path.

Do note that Gitlab will create a redirect if we move the project as long as you don't replace the old location with a new project.

Here what you can expect from Gitlab docs: https://docs.gitlab.com/ee/user/project/repository/index.html#what-happens-when-a-repository-path-changes

Well, that is actually what is different now because moving repositories was not initially planned (we were talking initially about an ignore path list). I am aware of GitLab's redirect feature but that has limitations - see CI include, we have to make sure that the redirected path is not claimed and we have to deal with client warnings. Also, we start defining check code logic that depends on repository structure which is not ideal. All this actually means that in order to be safe we will actually have to migrate the forks.

I'm wondering if we can find a different implementation approach to this. Could we rediscuss the initial proposal of handling a forks list that the tooling is able to ignore when dealing with ECA? Or maybe we could find a way to have each repository a way to "present" itself as a fork/3rd party component. For example, using repositories topics: if a repository has the topic fork, avoid ECA checks.

I am definitely open to making changes to our implementation since we created this feature to enable the Oniro project to do this. However, I was not expecting the project to be already maintaining forks.

Our goal was to solve #895 (closed). I was under the impression that the project was waiting for our implementation and @wbeaton approval before pushing forks: #895 (comment 542599)

It's possible that I missed a memo and I apologize for that if that's the case.

However, I now understand that the project has been doing this for a while which explains your reluctance to move which I can understand.

With that said, my first priority is unblocking the project.

@agherzan can you provide a list of all GL projects that the ECA must exclude? I am thinking @malowe can write an exception to our ECA git hook to ignore projects from your list while we work on a long-term solution.

Once that is done, would you mind creating an issuer under our ECA API project with your proposal on how we should manage forks we will see what we can do there for a long-term solution: https://gitlab.eclipse.org/eclipsefdn/it/api/git-eca-rest-api

Just to add more information.

We decide to require a namespace for forks since we wanted to ensure that 3rd project code was not placed in the same/group location as Eclipse project repos. By requiring a specific namespace, projects could identify forks/3rd-party by naming their group as such.

For example eclipse/oniro-core/3rd-party

So I suspect something more changed lately which now forces ECA on repositories that were not supposed to be checked.

We changed how we track Gitlab projects in the PMI after we found out that our PLs were creating new projects without making a request to webmaster. That was a side effect of granting PLs the maintainer role instead of the triage role: #17 (comment 256)

(Our Gitlab instance does not allow users with the developer role to create projects. We changed the default setting. Only users with maintainer role can create group/projects).

By doing so, these projects were not being tracked in the PMI which caused them to be ignored by our ECA. I think that is how you've been able to push code to your 3rd party forks.

We now track namespaces instead individual project URLs to allow more control to PL over the structure of their project without exposing us to any ECA issues.

@wbeaton Before we make any changes, can you confirm that you are good with all of this and you are fine with the location chosen by the project for the 3rd party forks?

@wbeaton We are waiting to hear from you before making any changes to unblock Oniro with 3rd party repos.

I understood, perhaps incorrectly, that we wanted 3rd party repos to be separated from Eclipse project repos. If that is not a real requirement, we can look at a solution for supporting the current structure that Oniro has.

@agherzan Can you please provide a list of all the 3rd party repos that the ECA must ignore? It will give a better understanding of the scope..

Thanks

I believe that earlier discussion related to #42 (closed) included consideration of a scenario where third-party forks could have their own group where they can be clearly distinguished from project content repositories. My expectation is that this is still a goal, but with all of the moving parts in Oniro right at the moment, reorganising isn't a priority.

As I stated in #1525 (comment 877606), this is a general problem for which we need a solution.

In the meantime, +1 to unblock Oniro.

@cguindon In https://gitlab.eclipse.org/eclipse/oniro-core, you will see all the repositories clearly marked as 3rd party/fork as part of their description. Here is an example:

3rd party: Fork of https://git.yoctoproject.org/linux-yocto

@malowe You can now move forward with implementing a temporary solution to unblock Oniro.

This will buy the project some time to re-organize their 3rd party structure and align with our new system for tracking 3rd party repos.

Let me know if you have any questions but I was thinking we simply hardcode an exception in our git hook for now.

Just to set expectations, there is a major outage with a major Internet provider in Ottawa which is impacting some of our employees. We might not be able to publish a fix today.

If not possible, we will publish our fix on Monday.

Thanks, @cguindon for the heads up.

mentioned in issue eclipsefdn/it/api/git-eca-rest-api#69 (closed)

mentioned in issue eclipsefdn/it/websites/projects.eclipse.org#103 (closed)

This is a general problem. I previously opened https://gitlab.eclipse.org/eclipsefdn/infrazilla/-/issues/468 (which we should consider moving to the public help desk) to discuss it.

Eclipse Oniro is not the only project that is working with forks. Off the top of my head, this also applies to Adoptium and the new Eclipse Muto and Eclipse Leda projects (all of these projects use GitHub).

These projects are not blocked if they are on Github. The ECA doesn't block contributions as we do on Gitlab.

mentioned in issue eclipsefdn/it/api/git-eca-rest-api#70 (closed)

Fix is live, applied to oniro-core forks. This will not apply to new forks, and any new forks would need to be added to an excluded namespace folder.

❯ git push origin HEAD -u
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Found allow listed project, skipping validation
remote: 
remote: To create a merge request for malowe/kirkstone/test, visit:
remote:   https://gitlab.eclipse.org/eclipse/oniro-core/meta-clang/-/merge_requests/new?merge_request%5Bsource_branch%5D=malowe%2Fkirkstone%2Ftest
remote: 
To gitlab.eclipse.org:eclipse/oniro-core/meta-clang.git
 * [new branch]      HEAD -> malowe/kirkstone/test
branch 'malowe/kirkstone/test' set up to track 'origin/malowe/kirkstone/test'.

@bero @agherzan You guys should be fully unblocked for now! I've tested by pushing to meta-clang and then deleting the branch just to make sure. We've manually tracked the repos in question to unblock at least oniro-core.

I'll be opening a new issue so we can communicate and track progress for migration into an excluded group for your forks!

Thanks, @malowe. Looks good and I have replied to the other issue too. Once again, we appreciate your support.

closed

mentioned in issue #1532 (closed)

Intermittent error pushing merge commits from upstream committers without CLA

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Designs

Child items ...

Activity