Review the git for comparison document

This commit contains fixes for git forge comparison document found during the
review of the document.

Signed-off-by: Michal Konecny <mkonecny@redhat.com>
This commit is contained in:
Michal Konecny 2024-09-20 16:53:09 +02:00
parent f1a1ebe624
commit e6b7319149
3 changed files with 27 additions and 16 deletions

View file

@ -12,9 +12,13 @@ Following is the investigation on GitLab based on the user stories collected.
It is possible to run CI jobs (https://docs.gitlab.com/ee/ci/) on GitLab on certain events (like pushes or pull request creation). For specific purposes where a custom environment is required, even custom GitLab runners (https://docs.gitlab.com/runner/) can be associated with a certain project repository or project namespace.
2. **As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit.**
Release Monitoring has an API (https://release-monitoring.org/static/docs/api.html) that can be attached as a webhook to an action on GitLab's end. This should help with controlling monitoring status of a certain package. This would require some work as there is nothing in GitLab that intrinsically supports this usecase.
For this to work on GitLab, we would need to have metadata stored in repository. This could be
for example stored in `.metadata` file. Anybody with commit rights to repository will be able to
change the monitoring settings.
Take, for instance, a GitLab CI job that observes changes (https://docs.gitlab.com/ee/ci/yaml/#ruleschanges) on a RPM specfile and act accordingly to do what is needed to update the monitoring status on Release Monitoring. Please note that there are multiple ways with which this can be done and this is just one of them.
Or we can leverage GitLab badges feature (https://docs.gitlab.com/17.2/ee/user/project/badges.html)
which could be accessed by the-new-hotness through API and the maintainer can set the correct
monitoring badge for the project.
3. **As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.**
GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and binding of user accounts with these groups can ensure that the user accounts are provided with necessary permissions (https://docs.gitlab.com/ee/user/permissions.html).
@ -24,7 +28,7 @@ Following is the investigation on GitLab based on the user stories collected.
4. **As a package maintainer and Fedora tooling maintainer, I'd like to be able to use Packit in both distgit and upstream repositories.**
Packit has an experimental support for GitLab as long as the GitLab instance is publicly available and Packit is made aware about the identity of the instance by manually configuring webhooks at GitLab end using the steps provided in the docs (https://packit.dev/docs/guide#gitlab).
The situation about the experiment support can change as soon as there are more stakeholders from Fedora Project requiring such support from the Packit's end, thereby maing it a primary requirement from not just the CentOS Stream repository workflow but also for Fedora Project.
The situation about the experiment support can change as soon as there are more stakeholders from Fedora Project requiring such support from the Packit's end, thereby making it a primary requirement from not just the CentOS Stream repository workflow but also for Fedora Project.
5. **As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.**
GitLab supports the use of badges (https://docs.gitlab.com/ee/user/project/badges.html) that provide a unified way of presenting condensed pieces of information about the project. While these are mostly used for showing status about the pipeline, statistics about the test coverage and information about the latest release - these can also be used for keeping links for Koji, Bodhi and Koschei for the said project.