---
tags: notes
---

Interesting fact about GitLab License https://en.wikipedia.org/wiki/Source-available_software

# dist-git on GitLab CE

For everything that is mentioned in here, we need an api so that we can use our tools to do other stuff that are connected to dist-git

## Questions

* Can we sync our FAS(Fedora Account System) groups to GitLab automatically on login ? IE if a member of the packager group in FAS logins in GitLab he will be automatically added to the packager group. (As I understand it this is an EE feature).

* There does not seems to be a way work GitLab to publish events on a messaging bus (like rabbitmq). How can this be implemented ? Are system hooks a possible solution ? Would such a service be interesting for GitLab ?

\[Notes: Our message bus delivers messages "in order", so consumers don't act on outdated data. According to ngompa, GitLab uses `sidekiq` for their webhooks which parallelizes event processing i.e. can't guarantee order. E.g., pagure -> copr care about the order of the messages (commit a, commit b).\]

* We want to leverage the Badges feature to offer links to other services. In the current state we would have to configure the badges for 30,000+ projects. Having https://gitlab.com/gitlab-org/gitlab/-/issues/22278 would allow us to do that configuration at a group level.

* We have many project with the character '+' in the name for example (c++-gtk-utils), it is currently not possible to create such projects. Is this something that can be configured or an actual limitation of GitLab ?

* How does the number of users in the minimun hardware requirements are calculated ? Is that the total of users that are registered in the instance ? or using the instance weekly ?

* Custom fields --> https://gitlab.com/gitlab-org/gitlab/-/issues/1906

## Works with GitLab CE
---
1. Authentication
https://docs.gitlab.com/ce/administration/auth/oidc.html

* OmniAuth supports OpenID Connect so we can use Ipsilon and hook it to Fedora's account.

## High Risk
---

1. Hosting vs Supported in Infra

* Hosted in cloud brings performance issues with fetching repo/data
* Supported in our Infra brings resources issues (hardware to run GitLab and time to do so)

2. How does that work with Koji ?

3. Use of bandwith.
* Mass Rebuild: Can we leverage creating commits from APIs https://python-gitlab.readthedocs.io/en/stable/gl_objects/commits.html#commits
* Mass Branching: Can we leverage creating new branches from APIs https://python-gitlab.readthedocs.io/en/stable/gl_objects/branches.html#branches
* koschei keeps rebuilding and thus keep re-cloning
* Any CI work will keep re-cloning repos

## Currently not supported in GitLab CE
---

1. Theming

Fedora and CentOS communities are both pretty attached to their branding, so they will want their dist-git to be easily linked to their project.

Theming also allows adding convenient links for each project, such as linking from dist-git to koji, bodhi, fedora-packages, COPR & so on.

We also use this to show the updates table (which version of the package is present on which Fedora/EPEL release).

* We can easily change the favicon and the logo display in the menubar, more theming might be hard.
* we can use Gitlab badges to provide links to external services, to make it easy to configure at group level we need (https://gitlab.com/gitlab-org/gitlab/-/issues/22278)

2. Integration with 3rd party tooling in the UI

We need a way to integrate 3rd party tooling in the UI displayed to the user.
For example in the case of anitya.

3. Project name must follow the following rule

'name': ["can contain only letters, digits, emojis, '_', '.', dash, space. It must start with letter, digit, emoji or '_'."]

For example https://src.fedoraproject.org/rpms/DivFix++ does not comply

## Needs More Info
---
1. Technical Limitations

I think gitlab has a limit of 10 queries per second, per IP. Which is great for most of the use cases, but during mass rebuilds and mass branching, we might need more than that. As during those two phases, we will pushing lots of stuff to the repos (basically creating new branches or committing to 30000 plus repos).

* Rate limit is something that can be configured by instance, so I think that we should be able to tune our instance to what we want. There is also the possibility to have different rate limits for authenticated requests against no-authenticated requests.

2. Groups
https://docs.gitlab.com/ce/user/group/

Groups are different in GitLab, there are groups of projects rather than groups of users.

Looks like GitLab groups are similar to Pagure's namespaces.(mohanboddu: I am confused with https://docs.gitlab.com/ce/user/group/#namespaces) So we could have an rpms, flatpaks, modules, containers, ... group.

We can link members to a group and give special permissions for the whole group. For example releng team or provenpackager will have more permissions.

* A group can have many subgroups.
* branch-protection can be managed at the group level
* Can transfer project from a group to another group
* Can share a project to another group
* Enforce 2FA for group members

**Note** There are legal reason for which some packages have restricted access, so no we can't give provenpackager access to everything

**Note**
cvsadmin access to everything
secondary/alternative arch group access to everything
provenpackager access to everything expect for "firefox" and "thunderbird"
access is normally not indicated (they do not show up in the list of people/groups having access to the repo) since they likely do not want to be notified of commits or PRs happening on the entire dist-git

3. Permissions
https://docs.gitlab.com/ce/user/permissions.html#permissions

Project Members in GitLab can be

* Guest
* Reporter
* Developer
* Maintainer
* Owner

**Notes** currently some of the permission checks are done by git hooks, is that an option with GitLab.

4. Branch level permissions

Certain people will have access to certain branches.
Reason: epel maintainers can access epel* branches. This should be configurable by regex as in epel* or el*

**Notes** --> branch protection ? (only to delete a branch ?)

5. Branch EOL

Each branch should have a EOL date (or something similar) so that people wont be able to push to those branches.
Reason: If a release goes EOL, we should not allow people to push changes to that branch. All the branches in Fedora has this requirement, but CentOS not.

**note:** the EOL date of a branch may change is Fn+2 slips, e.g.: if Fn+1 slips for 1 week and Fn+3 slips for 2 weeks, the EOL date of the branch for Fn is pushed back 3 weeks

* Protected branch offer the possibility to complitely disable pushing on a branch. Although this can be changed by maintainers.

6. Integrating with other tools:

Currently the EOL's are coming from PDC (https://pdc.fedoraproject.org/rest_api/v1/), when a user pushes to a branch, it will verify if the branch is active by checking with PDC and either allow the push or disallow it.

7. Hidden/Archived Branches

We don't need to show EOL'd release branches
Reason: We don't need to show all the branches that are fxx where xx<30 which are EOL'd.

8. A user cannot remove branches

People are not allowed to remove branches
Reason: Maintainers are not allowed to remove branches as we dont have a way to track whether a build got submitted from that branch before removing it.

**Notes** --> branch protection ? Ability to configure by namespaces or globally
**Notes** --> Certain groups (of users) can override this.

9. A user cannot change the git history

People are not allowed to push anything that changes the git history of the branch
Reason: Same as above, since we don't know what build was submitted from what git hash, we don't want to loose the history.

Question: If we ever needed to remove something, could we? (accepting the fact that we would rewrite history and loose links from koji builds to commits & so on)

10. Orphaning

We need the possibility of orphaning an entire project, or a specific branch.

This is currently handled by giving the project to the ``orphan`` user.
If there are other users who are maintaining the project, then assign the project to that user. This happens with unresponsive maintainer.

11. De-orphaning process

Packages who are maintained by the ``orphan`` user can be adopted by anyone if (all the following is satisfied):
- it was given to the ``orphan`` user for less than 8 weeks
- If the package was orphaned for more than 8 weeks, it was retired and the user should be informed that they should fill a releng ticket
- the person adopting it is a packager
- the package is still active (cf package status)

**Notes** This need to be granular Project Level but also at the branch level

12. Bugzilla overrides

dist-git needs a way for packagers to specify who is going to be the point of contact for "Fedora" and "Fedora EPEL" in bugzilla (this being for the ``rpms`` namespace, the other namespace don't need this distinction, but still need the override).

This should also support giving the overrides to a group.

Members of the cvsadmin group should be able to update these overrides.

**Notes** This is integrated within pagure's ui.

13. Interactions with the API restricted on group

Admins should be able to create projects, regular users not.

In the future, we may also need to add such restriction to API endpoints such as: add a git tag to the project.

14. Git seed

We're currently shipping a daily bundle of all the git repo to make it easier to download for people with low bandwith.

**Notes** is this something that can be provided by GitLab (we have a script that does this)

15. Tarball of all spec files

We're currently shipping a daily tarball of all the spec files in all the git repository to make it easier for people to analyze and make stats of them.

**Notes** is this something that can be provided by GitLab (we have a script that does this)

16. Single endpoint for all bugzilla main assignee

We need a single place where we can retrieve the list of all bugzilla main assignee for all projects hosted.

This is to avoid having to do 20k+ requests just to gather this information.

**Notes** Looks at the APIs (GraphQL **might be** useful here).

17. Single endpoint for all bugzilla CC

We need a single place where we can retrieve the list of people and group that should be CC'ed on tickets in bugzilla for all the projects hosted.

This is to avoid having to do 20k+ requests just to gather this information.

18. Single endpoint for all maintainers

We need a single place where we can retrieve the list of all the maintainers (users and groups) of all the projects hosted.

This is used to generate the ``<package name>``-owner@fp.o alias.

19. Issue tracking

Issue tracking should be configurable by admins on a per namespace basis.

E.G: in Fedora dist-git does not want issue tracking on except for the ``tests`` namespace on CentOS, the dist-git part of the instance also does not want issue tracking on while the project hosting part does.

20. A maintainer can toggle new branch creation

People want the ability to enable/disable the creation of new branches. Since we do not remove branches, they want to ensure new branches are not created by accident.
This setting must be something we can toggle in the UI and API as otherwise, we can't create the new branches at mass-branching or on user's requests.

21. Webhooks

Can we deploy webhooks in automated way (apply to all rpms, etc ...)

22. API tokens with admin access for regular users

We have a group of people processing the requests for new repos and new branches. Some of them are cvsadmin others are not.
We need to be able to give to regular contributors (ie: not cvsadmin) API tokens allowing them to perform the actions needed when processing new repo/branch requests without giving them full admin access/power.

23. How to make this work with our build system?

Considering that the builders do not talk to the internet and won't, how will we make this work?

* Question: is there any requirements on the MBS side for dist-git?

24. Prevent project deletion

Project on dist-git can not be deleted except for by very few admins. Users should not be able to delete projects.

25. An user cannot change the git tag

People are not allowed to change an existing tag in a git repository.

26. An user cannot add git tag on a specific namespace

With rpmautospec, we want to have a namespace of git tags that can only be filled by rpmautospec in koji, so regular users must not be allowed to add git tags on this specific namespace which would otherwise mess up with the version computing algorithm.