Exporting Namespace Assets From Pagure

A lot of projects related to Fedora Project and CentOS Project reside in Pagure which makes it important for us to understand the ways they can be interacted with and moved around when the need arises.

Elements for interaction

In this context, we are looking into interacting with the following elements:

Issue tickets

These can either be requests for adding new features, reporting of a bug, proposal of an idea or anything else. These need to be available in the place where the namespace assets get transferred to, in order to retain the context around the probable action items.

Repository assets

These are the actual files stored in the Git repository that pertains to the actual project. This can either be a codebase, a collection of documentation, a group of artworks or anything else. This happens to be the primary subject for the transfer.

We are avoiding interacting with the following elements

Pull requests

Not only does it require for the pull requests to be artificially created by a stub user (say, a bot user of some kind as we cannot guarantee the availability of the GitLab user pertaining to the related Pagure user) in the destination namespace but it also needs the source of the pull request (which can either be a fork of the source namespace of a branch inside the same repository) to be available, which might not always be the case. We strongly recommend merging all pending pull requests that are needed and closing those that are not, before the transfer process begins.

Ways of interaction

The elements that we would want to interact with, can be done so using the following ways.

Issue tickets

  • Pagure API

    This provides an extensive method to interact with the issue tickets pertaining to a certain source namespace. This can be expanded upon to receive information like issue title, issue content, assignees, tags, creation date, modified date, comments etc. Depending on what information and how much amount of it is requested from the API server, the interactions can be done quickly too, paving the way for automation. The service does not seem to have rate limiting too and hence, can be used without worry for interacting with bigger repositories.

    • The good

      • A well structured API query with limited scope can ensure that multiple requests are made and addressed quickly.

      • This does not require any local storage space to be available in order to make requests, unless caching is employed.

    • The bad

      • Extra assets bound to the issue ticket like images, documentation, media files etc. cannot be reliably accessed.

      • Service can be slow at times, leading to timeouts and hence, a condition to address those during automation is needed.

  • Issues Git URL

    For the users that have a commit access to a certain source namespace, they should be able to see an option for listing “Other Git URLs” on the project page. Although Pagure provides methods to clone both “Issues” and “Pull Requests” using those special Git URLs, we would only talk about that for the former. For instance, the folks having a commit access to the fedora-websites repository should be able to access the issue tickets using the URL ssh://git@pagure.io/tickets/fedora-websites.git.

    • The good

      • A clone of the issues repository can help receive all the issue tickets ever created in one fell swoop.

      • Extra assets bound to the issue ticket like images, documentation, media files etc. can be reliably accessed.

    • The bad

      • It can take a long time to fetch the issues repository in its entirety if the repository has had too many of those.

      • This mandatorily requires the use of a local storage space to be able to clone and make changes locally before publish.

Repository assets

  • Default Git URL

    Folks can access the repository assets of the source namespace using the default Git URL. Depending on the availability of the API keys for the users, they can choose to either interact with the repository assets with the use of either the HTTPS URL (for example, it would be https://pagure.io/fedora-websites.git for the fedora-websites source namespace) or the SSH URL (for example, it would be ssh://git@pagure.io/fedora-websites.git for the fedora-websites source namespace). We would not go in detail with the advantages and disadvantages of this method as there seems to be only one way to interact with repository assets.