[oniro] Migrate oniro-core excluded forks to their own group

As discovered in #1525 (closed), there are many forks existing in the oniro-core project group that are offside. These repositories should be moved to a special excluded folder to match up with the allowed for structure.

@agherzan here is the new issue where we can have a nice clean communication channel dedicated to this effort! Just to let you know before this effort starts, our goal is to support generally whatever subgroup structure you like going forward. This means that you could have a subgroup structure like the following:

eclipse/
├─ oniro-core/
│  ├─ forks/
│  │  ├─ infra/
│  │  │  ├─ meta-clang.git
│  │  ├─ os/
│  │  │  ├─ linux.git
│  ├─ oniro-core.git

Also as a little tip, we will be supporting a different way of grouping like projects soon. You'll be able to group projects under the top-level project as a domain-like structure, as well as create arbitrary groups in your project group, the following being an example:

eclipse/
├─ oniro/
│  ├─ oniro-core/
│  │  ├─ forks/
│  │  │  ├─ ...
│  │  ├─ core/
│  │  │  ├─ oniro-core.git
│  │  ├─ meta/
│  │  │  ├─ ...
│  ├─ oniro-blueprints/
│  │  ├─ doorlock/
│  │  │  ├─ doorlock.git
│  │  ├─ meta/
│  │  │  ├─ ...
│  │  ├─ blueprints/
│  │  │  ├─ ...

This does not allow for custom permissions, or people to be added on these further down subgroups. It will allow for better management of issues, like projects, and similar management things, however. I know that you'll be doing some work to do this, so I might as well show you what good came from this upgrade, right? ;)

cc @wbeaton @cguindon

assigned to @malowe

Note that I say soon, not to say the functionality isn't there, but to more do a slow rollout to some groups to push the system and play with it. This way we can make sure that the wrinkles are ironed for the Gitlab support team when it comes time to hand over the reins haha!

added Awaiting Feedback prioritymedium severitynormal stateblock labels

added team:webdev label

changed due date to September 30, 2022

I set due date to make sure this issue is not forgotten. We can delay if needed but we do need to get to this eventually.

marked this issue as related to eclipsefdn/it/api/git-eca-rest-api#71 (moved)

Thanks, @malowe. This is useful. We have managed to discuss this solution internally and we agree that in general having a subgroup with "forks" would make things a bit neater. I think the only aspect to clarify is the actual name of the subgroup. This is because it would hold both forks and also mirrors. And the distinction can either be clear (a mirror of an upstream source vs a repository with forked branches) but can also be a confusing mix. GitLab supports the ability to mirror a repository while handling divergent refs: https://docs.gitlab.com/ee/user/project/repository/mirror/push.html#keep-divergent-refs All these cases of "forks" would make the name a bit confusing. I don't yet have the perfect solution to this but other big projects use "third party" in different forms:

• third_party
• 3rd_party
• 3party
• etc.

I would vote for the first one above.

That being said, and given that we do have a solution in place, we won't be dealing with the migration for the existing 3rd party components soon as we are currently busy with the next release. The new forks (if any) thought, will adhere to the solution we decide.

Honestly, half way through your comment I thought about suggesting third-party as well haha! We prefer using dashes for consistency at the moment, but we aren't stuck hard and fast with that. If you are onboard with third-party, I can see about setting the group up today. I'd leave the actual migration of groups alone of course, but gives you the option to use it though.

Also keep in mind, you can add groups in this excluded group to better distinguish forks vs mirrors ;) More control will be yours!

I think we are good to go with that. And yes, I haven't thought about that flexibility but it does sound nice. Are we going to have a mention of this in the handbook?

Yes we will :) I have an MR up to add that to the handbook, its just been hectic last couple weeks and hasn't been merged in. You guys are the first group to be notified as well so we can do a soft rollout and ensure we've got all of our bases covered as well as docs needed for this.

https://gitlab.eclipse.org/eclipse/oniro-core/third-party has been created and added as an excluded path. Anything you guys create under this won't be managed with the ECA. Maintainers/Project leads can add sub groups to this to get the forks and mirror groups added as well. Left it up to you guys in case you wanted different nomenclature!

@malowe nit-pick - can we be consistent with the repository name too: third-party as opposed to Third-party?

You can rename the title of the group as long as the slug stays the same as that's what we care about. As you are a maintainer I believe you have the rights to do this. Let me know if you don't and I can do that operation.

@malowe we have a new blocker - our documentation infrastructure relies on a CI-owned, flattened repository of the documentation export: https://gitlab.eclipse.org/eclipse/oniro-core/oniro-readthedocs-aggregated. This allows us to expose to ReadTheDocs an aggregated view of all the documentation of the project (coming from multiple repositories). The issue is that while maintaining that "view", the CI pushes to it with a generic identity: Oniro Project CI <oniro-dev@eclipse.org>. Obviously, ECA fails for it: https://gitlab.eclipse.org/eclipse/oniro-core/docs/-/jobs/57506. We could use the identity of the CI owner if that would be acceptable, what do you think?

@agherzan I don't understand relation with this issue.

However, I created a PAT, and stored token in CI variables under CI_ONIRO_AGGREGATED_DOCS_TOKEN.

Can you modify your .gitlab-ci.ymland try to push with this bot!

@heurtemattes

1. It has a connection with this issue as this new blocker is a side effect of the ECA changes that have been merged lately enforcing ECA checks on all repositories. This issue (#1532 (closed)) implemented a workaround for the forks/mirrors but not a way forward for the infrastructure ones. Nevertheless, I have filed another issue: #1565 (closed).
2. I have no idea how the PAT was supposed to help in this case. I suspect that you haven't understood the issue at hand. Please take a look at #1565 (closed) and let's continue the discussion there.

I delete the PAT and let the webdev team answer to this problematic.

Yeah, I think we need to figure out some way to pull PATs/Gitlab bot users from the API at some point. I think its a nice to have as we already have a working process that uses the project bots API that works across our platforms.

mentioned in issue #1565 (closed)

@agherzan it looks like @fgurr created the bots API reference that you should be able to use for these automated build operations. Let me know if that solves your issue! I see you've got a few repos under the different groups that I love to see. Let us know if you have any other hiccups in adoption.

That worked and I've closed the associated issue. Thanks for your support.

mentioned in issue #1581 (closed)

@agherzan how's it going? Any blockers in the migration to the excluded forks area? I'd love to get rid of the bypass so we can all be in a clean state!

Thanks, @malowe for the touch base. No blockers for us besides time - we are working full steam for the next release and as I said in the initial issue, we will look into it when we have a breather. For now, I would like to keep the bypass and I'll update once we get to moving the repos accordingly.

mentioned in issue #42 (closed)

changed title from Migrate oniro-core excluded forks to their own group to [oniro] Migrate oniro-core excluded forks to their own group

@agherzan how's it going with this issue? We're closing on 2 months past the initial remove-by date and we wanted to check in if there are any blockers to this migration.

Hello, @malowe I am not in the position to help with this anymore. @toscalix, could you chase it so we can have someone look into it?

During the last Onito IT meeting Luca MIotto agreed to try to propose a decision to the PMC.

mentioned in merge request eclipse/oniro-core/oniro!339

@malowe any actions on EF side? Or can I close this issue?

This issue is can't be considered finished until we can remove our ECA exception for oniro-core in our git hook on Gitlab: https://gitlab.eclipse.org/eclipsefdn/it/api/git-eca-rest-api/-/blob/main/src/main/rb/eca.rb#L11

ok, IIUC, all these projects must be moved to https://gitlab.eclipse.org/eclipse/oniro-core/third-party/forks?

What is the priority/severity for you? in order to adjust the ticket and maybe define a new due date.

/cc @scorbett see last comment from Agustin to report to PMC: #1532 (comment 1069211)

Exceptions lead to confusion.

For the end user, repos that aren't validated with the ECA, should be moved and only exist in the third-party group!

We were hoping this would have been resolved by now.

Only these projects have been migrated to the thrid-party gitlab group:

Remains:

• '/eclipse/oniro-core/linux',
• '/eclipse/oniro-core/linux-meta',
• '/eclipse/oniro-core/llvm-project',
• '/eclipse/oniro-core/meta-arm',
• '/eclipse/oniro-core/meta-av96',
• '/eclipse/oniro-core/meta-binaryaudit',
• '/eclipse/oniro-core/meta-clang',
• '/eclipse/oniro-core/meta-openembedded',
• '/eclipse/oniro-core/meta-riscv',

This is an EMO issue as far as I can tell and not a working group or program manager issue. Wayne Beaton's success team should take over?

cc @wbeaton

@malowe @cguindon @heurtemattes anything we can do to be able to close this issue?

This is all on the project side at this point, as we can't remove the bypass we have without breaking the listed project mirrors which is something we want to avoid if at all possible. The project has been offside for over a year at this point, and have done no work to rectify this in that time. I think this might be something @wbeaton and his team has to chase down at this point.

@jricoeclipse I think this ticket is also part of what we were discussing about closing oniro issues. If you can confirm.

I removed the due date of September 30, 2022 since we are past that and set a due date of January 31, 2025 to close this issue.

Any update on this?

@heurtemattes @cguindon please close it.

sorry missing it.

@jricoeclipse can you elaborate on what you mean by close it? Looking into this, we're in the same state that we were ~2y ago, with the same list as above still listed as forks and not in the separate namespace. If this is closed without addressing the issue and we remove the exception, the above mentioned projects would not be able to pull upstream commits from the parent repository and would likely block work for the Oniro project.

Checking in on this, @jricoeclipse could you expand on the above comment? I want to understand where we should go with this as the project has been offside for over 2.5y at this point, and has an associated technical debt in our scripts.

Hi @malowe sorry for the late reply.

Those issues were opened before I joined and have never been touched on in any of the Oniro conversations I have had. I don't understand what the challenge is or what change is required to be ok again, but these projects were discontinued in July 2023.

Hope this helps and also happy to jump in a call to discuss implications and more details.

Thanks

Looking it up and yup, there is no activity on this project for the past year as per PMI: https://projects.eclipse.org/projects/oniro.oniro-core. I'm thinking I remove the exceptions from our ECA script then, and we can deploy that next week and close this out!

thanks @malowe

removed due date September 30, 2022

changed due date to January 31, 2025

Closing as the remaining code was removed and will be live the next time we update the ECA check for Gitlab. Thanks all!

closed

removed stateblock label