| |
@@ -0,0 +1,181 @@
|
| |
+ .. _gitlab:
|
| |
+
|
| |
+ GitLab
|
| |
+ ======
|
| |
+
|
| |
+ User stories
|
| |
+ ------------
|
| |
+
|
| |
+ Following is the investigation on GitLab based on the user stories collected.
|
| |
+
|
| |
+ 1. **As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.**
|
| |
+ 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.
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ 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).
|
| |
+
|
| |
+ In this specific case, the proven packager group can be provided with the maintainer-level access so that they can have push and merge access to all packages available in the Fedora Project package repository while the releng-scm-bot can be provided with the owner-level access.
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ Take, for instance, these badges can be configured automatically whenever the repository is created for the first time by the releng-scm-bot either in the repository level or as a part of textual links in the README.md file in the project repository. Alternatively, the URL field for the project can be configured to store the Fedora Packages URL (https://packages.fedoraproject.org/).
|
| |
+
|
| |
+ 6. **As a packager sponsor/mentor, I'd like to help users from outside the packager make their first PR without requiring special tooling or authentication schemes.**
|
| |
+ As mentioned in the answer to the user story #3, GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and it is also possible for the administrators (https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html) the customise the behaviours of these roles - thereby allowing for users who do not necessarily belong from the packagers group to be able to make pull requests to another project repository as long as the project repository is accessible to them.
|
| |
+
|
| |
+ 7. **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.**
|
| |
+ GitLab provides for extensive customization of labels (https://docs.gitlab.com/ee/user/project/labels.html) and interweaving of issue tickets (https://docs.gitlab.com/ee/user/project/issues/related_issues.html) which can be used to denote circumstances where a certain issue ticket depends on another issue ticket and where a certain issue ticket is blocked on another issue ticket.
|
| |
+
|
| |
+ 8. **As a package maintainer, I'd like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.**
|
| |
+ GitLab provides with a comprehensive REST API (https://docs.gitlab.com/ee/api/rest/) that can be used to extend the GitLab instance's functionality using external applications and services. Fedpkg (https://pagure.io/fedpkg) needs to be reworked to associate the REST API endpoint that allows for interacting with the deployed instance in accordance to the REST API schema of GitLab.
|
| |
+
|
| |
+ 9. **As a package maintainer, I want to be able to control all aspects of the pull request process (read comments, reply to comments, approve PRs, merge PRs, etc) via an REST API to allow creation command line tools to automate work that otherwise requires a pointy-clicky web UI.**
|
| |
+ As mentioned in the answer to the user story #8, GitLab provides with a comprehensive REST API (https://docs.gitlab.com/ee/api/rest/) that can be used to perform actions that control all aspects of a pull request process (https://docs.gitlab.com/ee/api/merge_requests.html and https://docs.gitlab.com/ee/api/merge_request_approvals.html). This REST API can be included in command line tools for automation.
|
| |
+
|
| |
+ 10. **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.**
|
| |
+ Introducing Mergify! Mergify (https://mergify.com/) allows for automated merging of pull requests whenever a certain set of conditions are satisfied. The conditions for pull requests can be set as all CI jobs to complete successfully. Mergify also supports GitLab (https://docs.mergify.com/integrations/gitlab/).
|
| |
+
|
| |
+ Alternatively, the inbuilt Auto-merge functionality (https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html) of GitLab can be used for merging pull requests for which all the conditions satisfy. Even this has an REST API access for circumstances where tailor-fitting is required.
|
| |
+
|
| |
+ 11. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**
|
| |
+ Project members associated with a certain GitLab project repository section can be found in the Project members section along with all necessary information like what level of access they have (eg. guest, reporter, developer, maintainer, owner etc.), the date of expiration of their access to the project (if set), the date of their user account creation, the date of their addition to the project repository or namespace, the date of the last access made by the user account etc. (https://docs.gitlab.com/ee/user/project/members/)
|
| |
+
|
| |
+ 12. **As a contributor, I want to be able to request to join the maintainer(s) for a package, either as a watcher (just notified of all PRs), or as a developer (participate in MR process), or as a maintainer (control all aspects of the package, ie user ACLs). Joining as merely a watcher should not require approval by current maintainers.**
|
| |
+ As mentioned in the answer to the user story #3, GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and it is possible for external collaborators to request for and for namespace/project collaborators to provide with these accesses as long as they are allowed to perform such actions.
|
| |
+
|
| |
+ The notification settings can be configured per repository without needing a prior permission of the owner or maintainer of the namespace/project to get informed about the activities taking place in a certain namespace/project repository (https://docs.gitlab.com/ee/user/profile/notifications.html).
|
| |
+
|
| |
+ 13. **As a package maintainer, I want opening a MR to automatically create a scratch-build. Approving the MR, should be able to either automatically promote the scratch-build to non-scratch status, or create a new non-scratch build. The latter should have a way to disable for packages with huge build times where creation of one build for multiple approved MRs is desirable for efficiency.**
|
| |
+ Creation of a scratch builds based on the branch from which a pull request was created is possible with the use of GitLab CI. Furthermore, the approval of a pull request can be associated with a GitLab webhook (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) which in turn should trigger the normal builds. Although, conditional cancelling of jobs due to them being overriden by a more recent job is something that needs to be configured using the GitLab CI configuration but it is possible (https://docs.gitlab.com/ee/ci/yaml/).
|
| |
+
|
| |
+ 14. **As a package maintainer, I would like to see the dependencies of this package, and what packages that are required by this package on web UI.**
|
| |
+ While this is a feature that can be created with the use of some intelligent parsing of the output taken from MDAPI (https://mdapi.fedoraproject.org/), the more elegant version of this implementation is unfortunately behind a paywall (https://docs.gitlab.com/ee/user/application_security/dependency_list/).
|
| |
+
|
| |
+ Focussing on making lemonades out of whatever lemons we have at hand, the endpoints PKG (eg. https://mdapi.fedoraproject.org/rawhide/pkg/nano) and REQUIRES (eg. https://mdapi.fedoraproject.org/rawhide/requires/nano) can be used to automatically populate the packages required by the project's package and the packages requiring the project's package respectively in custom files when the associated package's repositories are being created for the first time.
|
| |
+
|
| |
+ 15. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**
|
| |
+ Please check the answer to the user story #11.
|
| |
+
|
| |
+ 16. **As a contributor, I want to be able to see the contributors that have contributed to this package.**
|
| |
+ Please check the answer to the user story #11.
|
| |
+
|
| |
+ 17. **As a packager I want to be able to have commit access without being added to the bugzilla watch list.**
|
| |
+ Please check the answer to the user story #12.
|
| |
+
|
| |
+ 18. **As a community member I want the ability to be added to the bugzilla watch list for a package without having commits or being in the packager group.**
|
| |
+ Please check the answer to the user story #12.
|
| |
+
|
| |
+ 19. **As a Fedora Infrastructure member, I want to ensure people who sign in to watch a package on bugzilla have a valid bugzilla account associated with their FAS account.**
|
| |
+ As we plan on deprecating Bugzilla going forward for its use in the packaging workflow and introducing the ticketing mechanism associated with the git forge solution that we choose as a replacement for the same, the notification settings pertaining to certain users can be configured per repository (https://docs.gitlab.com/ee/user/profile/notifications.html) as long as they have an account in the said git forge solution.
|
| |
+
|
| |
+ 20. **As a user of Fedora, not necessarily a member of the Fedora Project, I want to receive information about Fedora packages in the form of readable HTML documents, not in the form of programs (in Javascript or Web Assembly) that I must execute before I get to see the information.**
|
| |
+ I am afraid Dist Git might not be the correct place for this requirement. Please defer to using Fedora Packages (https://packages.fedoraproject.org/) for obtaining information about packages available in the official Fedora Project repositories. We do not want to duplicate efforts by reproducing features in Dist Git that are already implemented in an associated project in Fedora Infrastructure.
|
| |
+
|
| |
+ 21. **As a security-conscious packager, I want to interact with the web interface without downloading and running programs from a bunch of third parties. I should at most need to whitelist Javascript and Web Assembly from fedoraproject.org only.**
|
| |
+ The set of JavaScript and WebAssembly tools involved in running a managed GitLab deployment are made available from the source hosting the deployment and not anywhere else. This has been analysed by observing the network behaviour made in a browser environment against a managed GitLab deployment intended for testing.
|
| |
+
|
| |
+ 22. **As a member of the Free Software movement, I want all parts of the system to be Free Software. That includes both server-side software and all Javascript, Web Assembly and/or CSS that my browser will download and execute.**
|
| |
+ Licensed under the permissive MIT license, GitLab Community Edition is a free and open-source software. The repository of the project codebase can be found at https://gitlab.com/rluna-gitlab/gitlab-ce. There are certain parts of proprietary code involved in the said repository but there is also a pure FOSS variant of it available at https://gitlab.com/gitlab-org/gitlab-foss/ and the actual codebase available at https://gitlab.com/gitlab-org/gitlab. I suspect that there would be certain limitations in the pure FOSS variant but I cannot yet verify the same.
|
| |
+
|
| |
+ 23. **As a package maintainer, I want to be able to use a pull-request-only workflow for specific packages (like packages that could break a lot of things, or packages that are security sensitive).**
|
| |
+ With the use of Protected branches mechanism (https://docs.gitlab.com/ee/user/project/protected_branches.html) of GitLab, one can ensure that changes to a certain set of branches can only be introduced using a pull request workflow.
|
| |
+
|
| |
+ 24. **As a package maintainer with provenpackager or scm-admin rights, I want to be able to circumvent pull-request-only requirements on packages when pushing changes (i.e. mass rebuilds).**
|
| |
+ The specifics of the which set of users are restricted by the condition mentioned and the ones that are not can be set using the information found in the answer to the user story #3. According to the answer to the user story #6, this behaviour can be further customized by the administrators to ensure that the ones with the elevated privileges are left unrestricted.
|
| |
+
|
| |
+ 25. **As a package maintainer, I'd like existing STI and TMT CI tests to continue working while also providing a simpler, more familiar YAML-based format.**
|
| |
+ As mentioned in the answer to the user story #1, as long as the GitLab CI is configured properly to support STI and TMT CI tests, they should work fine on GitLab like they do on Pagure - both in environments provided within the managed GitLab infrastructure and in custom GitLab runners introduced externally.
|
| |
+
|
| |
+ 26. **As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.**
|
| |
+ Please check the answer to the user story #23.
|
| |
+
|
| |
+ 27. **As a package maintainer, I want to be able to deal with bugs directly from the forge, and be able to reassign them between projects.**
|
| |
+ GitLab provides with the functionality of creating namespaces (https://docs.gitlab.com/ee/user/namespace/) that can have either multiple namespaces or project repositories associated with them. As long as the issue tickets are created for the project repository in a certain namespace or for the namespace in its entirety, they can be reassigned with other project repositories belonging to the same namespace.
|
| |
+
|
| |
+ 28. **As a package maintainer, I want to be able to sync a fork with the upstream with a button click.**
|
| |
+ GitLab user interface provides a nifty button for allowing folks to update their repository forks if they were to fall out of sync (https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#from-the-ui). Alternatively, people can rely on GitLab CI as mentioned in the answer to the user story #1 to automate the process by periodically updating a certain set of branches in their fork.
|
| |
+
|
| |
+ 29. **As a package maintainer, I wish we had CI compatible with Github Actions.**
|
| |
+ While GitHub Actions and GitLab CI are not inherently compatible with each other, they do work in a similar manner and there are a bunch of documentation that explain how one can migrate from GitHub Actions to GitLab CI conveniently (https://docs.gitlab.com/ee/ci/migration/github_actions.html).
|
| |
+
|
| |
+ 30. **As a contributor, I'd like to be able to interact with git and distgit via email, namely to reply to issue and PR comments.**
|
| |
+ As mentioned in the answer to the user story #12, the notification settings can not only be used to for obtaining information via email about the activities associated to a certain namespace/project repository but also to reply to issues or pull requests via email as well - establishing a two-way communication medium.
|
| |
+
|
| |
+ 31. **A contributor, I'd like to be able to create repositories under a personal namespace for work related to Fedora.**
|
| |
+ Please check the answer to the user story #27.
|
| |
+
|
| |
+ 32. **As a package maintainer, I'd like to block branch creation outside of official ones, or remove branches outside of official ones.**
|
| |
+ GitLab provides means to name, manage and protect Git branches according to a certain configuration (https://docs.gitlab.com/ee/user/project/repository/branches/#view-branches-with-configured-protections). This feature can be used to create branch with names following a certain regular expression pattern (eg. f39, f40, rawhide etc.) to protection while other branches might or might not be protected.
|
| |
+
|
| |
+ 33. **As a contributor, I'd like the forge to be accessible (alt text for images, respecting whatwg standards for contrast, color blindness, aria support).**
|
| |
+ GitLab pays attention to established accessibility standards (https://docs.gitlab.com/ee/development/fe_guide/accessibility/) while the extent of support can be subjective in nature. It might be enough for a certain set of people with special needs while it might not be the same for others and hence, I propose further investigation on this from the Accessibility WG.
|
| |
+
|
| |
+ 34. **As a package maintainer I'd like to be able to delete a wrong file from the look aside cache.**
|
| |
+ As we are proposing the use of Git LFS (https://git-lfs.com/) for the storage of tarball archives and GitLab inherently supports it (https://docs.gitlab.com/ee/topics/git/lfs/), it should be as easy as pushing a file removal commit in order for deleting a previously added file to the lookaside cache. We understand that a similar set of changes also need to be introduced to fedpkg (https://pagure.io/fedpkg) in order to ensure that the commands associated with interacting with the lookaside cache play well with the Git LFS based solution.
|
| |
+
|
| |
+ 35. **As a package maintainer, I'd wish to be able to see a tree of the Depends-on and Blocks bugs relationship, and export it to JSON or any easily processable document.**
|
| |
+ As mentioned in the answer to the user story #7, the interweaving of issues is possible (https://docs.gitlab.com/ee/user/project/issues/related_issues.html) and these issue tickets can be exported out easily in the form of CSV (Comma Separated Values) files (https://docs.gitlab.com/ee/user/project/issues/csv_export.html) from the GitLab user interface as long as the user requesting for the export has at least the reporter access to the associated project namespace or repository.
|
| |
+
|
| |
+ 36. **As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.**
|
| |
+ While this is a feature that can be implemented with the use of Renovate (https://www.mend.io/free-developer-tools/renovate/) and GitLab support for Renovate (https://docs.renovatebot.com/modules/platform/gitlab/), the more elegant version of this implementation is unfortunately behind a paywall.
|
| |
+
|
| |
+ Focussing on making lemonades out of whatever lemons we have at hand, Renovate can be automatically configured to help report CVEs related to the dependencies and remedial pull requests that help with upgrading from the affected version whenever the repositories are created for the first time by releng-scm-bot.
|
| |
+
|
| |
+ 37. **As a package maintainer, I still want to be able to use Grokmirror to mirror the Forge packages locally.**
|
| |
+ To Grokmirror's credit (https://github.com/mricon/grokmirror), the project is open enough to allow for mirroring from and mirroring to most Git forges as long as their JSON schema for their REST API is readily available. It should be possible to mirror repositories available on the chosen Git forge replacement to people's mirrors as long as the destination repos are empty as mentioned in Grokmirror.
|
| |
+
|
| |
+ Additionally, repository mirroring (https://docs.gitlab.com/ee/user/project/repository/mirror/) is a feature available across multiple tiers of GitLab with the support for various Git forges for not only the contents of the Git repository but also the pull requests and issue tickets associated with it. One can also make use of GitLab CI (https://docs.gitlab.com/ee/ci/) to set a cronjob or event driven interaction.
|
| |
+
|
| |
+ 38. **As an engineer involved in the release process, I want to be able to track blocker bugs and freeze exception bugs in the chosen issue tracker.**
|
| |
+ GitLab provides issue trackers (https://docs.gitlab.com/ee/user/project/issues/) associated with a certain namespace for purposes like discussing the implementation of an idea, tracking tasks and work progress, accepting feature proposals, questions, requests or bugs, elaborating on code implementations etc.
|
| |
+
|
| |
+ Additionally, as mentioned in the answer to the user story #7, if the interweaving of the issue tickets across various namespaces is a requirement due to cases like a certain package depending on another package - this can be facilitated by ensuring that the issue tracker associated with the parent namespace of the said packages are used.
|
| |
+
|
| |
+ 39. **As an engineer involved in the release process, I want to be able to properly triage the state of the blocker bugs and freeze exception bugs with Kanban boards.**
|
| |
+ GitLab provides some cool looking issue boards (https://docs.gitlab.com/ee/user/project/issue_board.html) that are blissfully unrestricted and available across various tiers. These issue boards follow the Kanban or Scrum methodologies for planning, triaging and implementing tasks associated with the namespace.
|
| |
+
|
| |
+ These can be mixed and matched with the use of epics (https://docs.gitlab.com/ee/user/group/epics/), milestones (https://docs.gitlab.com/ee/user/project/milestones/) and issues (https://docs.gitlab.com/ee/user/project/issues/) to ensure that the progress reporting is verbose and effective in the software engineering process.
|
| |
+
|
| |
+ 40. **As an engineer involved in the release process, I should be able to notify the affected package maintainers and package testers.**
|
| |
+ Please check the answer to the user story #12.
|
| |
+
|
| |
+ 41. **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.**
|
| |
+ While the roadmap feature (https://docs.gitlab.com/ee/user/group/roadmap/) is unfortunately behind a paywall, some intelligent use of the time tracking feature (https://docs.gitlab.com/ee/user/project/time_tracking.html) which is available across all the tiers should allow for us to have a similar effect of using a Gantt chart for tracking the various stages of the release process.
|
| |
+
|
| |
+ 42. **As an engineer involved in the release process, I want to be able to control the automated building and testing using comments.**
|
| |
+ As mentioned in the answer to the user story #13, the events possible with GitLab CI like the creation of scratch builds and actual buiilds can be controlled with the intelligent use of webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) that GitLab supports. These webhooks can be triggered internally on the selected git forge as a consequence of activities like commenting under a ticket or a pull request or externally with the use of projects like Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging).
|
| |
+
|
| |
+ 43. **As an engineer involved in the release process, I want to be able to triage the priorities of the blocker bugs and freeze exception bugs in the chosen issue tracker.**
|
| |
+ Please check the answer to the user story #7.
|
| |
+
|
| |
+ 44. **As an engineer involved in the release process, I want to be able to speed up the creation of blocker bugs and freeze exception bugs with the use of issue ticket templates.**
|
| |
+ As mentioned in the answer to the user story #37, GitLab not only provides for issue trackers but also description templates (https://docs.gitlab.com/ee/user/project/description_templates.html) working on both issue tickets (https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template) and pull requests (https://docs.gitlab.com/ee/user/project/description_templates.html#create-a-merge-request-template) that are available across all tiers for usage.
|
| |
+
|
| |
+ 45. **As an engineer involved in the release process, I want to be able to limit the access of ticket modification to a certain set of people.**
|
| |
+ Please check the answer to the user story #3.
|
| |
+
|
| |
+ 46. **As an engineer involved in the release process, I want to be able to access the chosen issue tracker with the use of an HTTP API.**
|
| |
+ Please check the answer to the user story #7.
|
| |
+
|
| |
+ 47. **As an engineer involved in the release process, I want to be able to show related issue tickets to the reporter to avoid repeated rejections.**
|
| |
+ GitLab shows related or similar issue tickets to the issue reporter based on the textual analysis (https://docs.gitlab.com/ee/user/project/issues/create_issues.html) of the issue content typed so far (both, head and description) in realtime without having to create the issue ticket first. This helps to ensure that the issue reporters are discouraged from reporting similar issue tickets if the same has been created before and instead they can be redirected to one of the existing ones to chime in.
|
| |
+
|
| |
+ 48. **As an engineer involved in the release process, I want to be able to use the already established Bug Status Workflow as closely as possible.**
|
| |
+ Please check the answer to the user story #7.
|
| |
+
|
| |
+ 49. **As an engineer involved in the release process, I want to be able to automate ticketing workflows according to the phases of a release.**
|
| |
+ With the use of the milestones feature (https://docs.gitlab.com/ee/user/project/milestones/) of GitLab which is available across various tiers, it is possible to control the behaviour of the namespace based on an event associated with a milestone. Actions like creating, editing, closing and deleting a milestone have effect on the namespace and can be tailored to ensure that they meet the requirements intended for the namespace.
|
| |
+
|
| |
+ 50. **As an engineer involved in the release process, I want to be able to track accepted previous release blocker bugs in the chosen issue tracker.**
|
| |
+ Please check the answer to the user story #7.
|
| |
t0xic0der
commented 20 days ago
Signed-off-by: Akashdeep Dhar akashdeep.dhar@gmail.com