Correct, the folks driving the investigation have been asked by Fedora Council to scope Forgejo and GitLab Community Edition as the two option best suited to the project to migrate to. Please bear in mind that this investigation is primarily focusing on the dist-git layer of the project, which is at the core of our build and release process for Fedora.
3 Likes
I’m looking at:
As a package maintainer and tooling maintainer, I’d like to be able to set Depends-on: and Blocks: relationships between tickets in the issue tracker.
Forgejo provides rudimentary issue tracking capabilities and while issues can be linked against each other superficially with the use of comments under an issue ticket thread (Automatically Linked References in Issues, Pull Requests and Commit Messages | Forgejo – Beyond coding. We forge.), they cannot be logically bound with each other. There is extensive customizations of labels possible (Labels | Forgejo – Beyond coding. We forge.) for scoping purposes.
Codeberg has depends / blocks metadata for issues. The UI is clunky (slow – seems to search all issues on codeberg?) but I think it’s there. Is it not in non-Codeberg Forgejo?
For
- As a package maintainer, I want to be able to mark a PR to automatically merge if-and-only-if a running CI pipeline has succeeded. This allows reviewing and approving a PR, and moving onto new work, without having to wait around to see if CI passes or not. The PR only needs re-visiting manually if CI failed.
The GitLab answer references something called “Mergify”. This appears to be a proprietary SaaS offering.
In any case, I think we want to drive this workflow from our CI engine, rather than relying too deeply on specific gitforge features.
- As an engineer involved in the release process, I want to be able to plan for the effects on release phases (Alpha, Beta, Final) using the Gantt chart.
Forgejo does not support roadmaps or time tracking in issue tickets.
Although it doesn’t have Gantt charts, issues can be assigned to milestones. (There is also a issue time-tracking feature, but I don’t think that’s something we really need.)
To give this a try, I’ve pushed the manifests for the Atomic Desktops in both forges:
- atomic-desktops/ci-test: Test repo for the Atomic Desktops - Forgejo: Beyond coding. We forge.
- atomic-desktops / ci-test · GitLab
Unfortunately, we don’t have CI setup in neither instances (the GitLab one does not have any runners and the Forgejo runners are all off), so I can’t really test more.
This is the first point on the list in the comparison in GitLab — ARC notes documentation & Forgejo — ARC notes documentation so it would be good to get something up so that we can test it as well.
Thanks for bringing this to our attention!
@ryanlerch and @dkirwan, how possible is it for us to set the CI up in the testing deployments?
The runner configured in Gitlab is only accessible within the Fedora group.
I just invited all the current users to the Fedora group, so should be able to access the runner now.
2 Likes
Just troubleshooting the Forgejo runner, something funny going on will take a look and try redeploying it. Hopefully get it back up and ready to use asap.
1 Like
The forgejo runner is now up and running correctly, can you please take a look and see if you are able to access it! Thanks.
2 Likes
I’m able to login without issue.
1 Like
On GitLab, I don’t have permissions to create sub-groups in the Fedora one. Are the runners only available for projects in this group? I had created another group for the Atomic Desktops.
Looks like the Forgejo runner works! Thanks
I’ll create this subgroup for you, if you want to take another look!
1 Like
I’ve created fedora / Atomic Desktops / ci-test · GitLab but I’m not an admin of the repo so I can not create the default branch nor push it.
1 Like
I’ve updated the permissions should have elevated permissions now.
Just a heads up, if you are getting any weird redirects and warnings about insecure connection as you are clicking through the menus, there is a misconfiguration I’m trying to track down here but it might need to wait until later to resolve as it might require a full reinstall of the gitlab instance. Just remove the gitlab. at the front of any URLs in such a redirect.
1 Like
Apologies I went messing with this gitlab config I’ve gotten past the issue so it should no longer redirect weirdly when clicking through some menus, but unfortunately now I’ve got TLS cert issues, its possible to continue to use gitlab, but you might have to bypass the self signed cert security warnings.
1 Like
Following on from this previous post of mine, the configuration change made has changed the URL which you can access gitlab to the following:
https://gitlab.gitlab-gitlab-system.apps.fedora.cj14.p1.openshiftapps.com/
again just to be aware there is a self signed cert issue, just accept and continue to access the system. (I’ll continue looking at the configuration to try get this certificate chain correctly configured)
1 Like
Heh, it was very easy to set up CI for a project on forgejo (for someone like me who already used GitHub actions a bit):
Though it looks like the action is stuck now trying to install nodejs 
I feel you, forgejo.
What I really like here is that it’s very easy to use reusable / modular components. That would probably be very useful for setting up CI in dist-git (since packages will likely all have identical setup steps for their CI pipeline). I don’t think this is possible with GitLab CI?
1 Like
With GitLab CI you can include manifests from other repositories: Use CI/CD configuration from other files | GitLab
This is heavily used to setup CI for applications in the GNOME & KDE GitLab instances.
Hm, this looks like it does a different thing, i.e. only include + merge whole CI pipelines, not pick-and-choose individual components? We use a common CI pipeline for most sequoia-pgp projects on GitLab, but that setup is often brittle because you can’t customize it well.
1 Like
You can split your template however you choose. Here is an example for a KDE application:
For example, all applications in KDE GitLab CI are built as Flatpak from the same template:
We could certainly do the same for RPM packaging.
Forgejo Actions are similar to GitHub Actions (Forgejo Actions user guide | Forgejo – Beyond coding. We forge.) and we could indeed create a set of Actions that do the RPM packaging and testing in a similar fashion to what’s done today in Zuul/Testing Farm.
Or we could also plug the existing CI (Zuul/Testing Farm) to it to get up to speed quicker.
I regularly use both GitLab CI & GitHub Actions and they both have their advantages and downsides.
1 Like