Changes/AutomatedPackitOnboarding

Automated onboarding to Packit release automation for new packages

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

To ease the onboarding process for package maintainers and their release workflows, we propose to automatically create pull requests with the initial Packit configuration file for newly created projects at src.fedoraproject.org. Once merged, this configuration will enable Packit to automate the release process, reducing repetitive tasks for maintainers.

Owner

• Name: Laura Barcziová, František Lachman, Nikola Forró, Maja Massarini, Matej Focko
• Email: lbarczio@redhat.com, flachman@redhat.com, nforro@redhat.com, mmassari@redhat.com, mfocko@redhat.com

Current status

• Targeted release: Fedora Linux 42
• Last updated: 2024-12-04
• [Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

This proposal introduces a mechanism to simplify the onboarding of Fedora package maintainers to Packit by removing the need to create the configuration manually. When a new project is created at src.fedoraproject.org, a pull request with a default Packit configuration file will automatically be opened.

Our proposal would be to add a CLI argument to the fedpkg request-repo command, similar to the existing argument --monitor. By default, this argument would be enabled and it would result in a Packit pull request being created upon the creation of a new repository. For maintainers who prefer not to have a Packit pull request created, this can be easily disabled by setting the relevant CLI argument during the repository creation request.

Once the pull request is merged, this configuration will:

• Automate the process of opening pull requests for updates when upstream releases occur (triggered by Upstream Release Monitoring), including necessary changes to the spec file and sources.
• Handle subsequent Koji builds and Bodhi updates after the pull requests are merged by the maintainer.

The automation would be configured by default to operate only on rawhide.

This ensures that maintainers no longer need to spend time on repetitive release-related tasks. Instead, they can focus on package quality and innovation. The pull request will also contain detailed instructions explaining:

• What is Packit and how the default configuration works.
• How maintainers can customize it to suit their project’s needs, such as disabling certain tasks.
• The steps to opt out of the automated pull request process.

Feedback

Discussions have indicated an interest in opt-out possibilities. As mentioned above, our current proposal would be implementing the opt-out via a CLI argument when requesting the repository creation.

Benefit to Fedora

This change aims to:

• Simplify the initial setup process for using Packit, reducing barriers for Fedora package maintainers.
• Decrease the time and effort spent on repetitive release-related tasks, allowing maintainers to focus on their packages’ quality and innovation.
• Provide maintainers with clear guidance and support for customizing or opting out of automation to ensure the system is flexible and user-friendly.
• Introduce Packit to maintainers as they create new packages, starting with typically simpler projects that are easier to automate, making it a good opportunity for them to learn about Packit.

Scope

• Proposal owners:

1. Implement automated pull request creation and integrate it into src.fedoraproject.org workflows (probably via fedpkg request-repo command and the related scripts for repo creation).
2. Document the new process thoroughly.
3. Followup support for users in the created PRs.

• Other developers:

This will be very isolated change that shouldn’t require much (if any) work done by other developers. If we contribute the code to the repo creation functionality, we would just need some guidance/review on these changes.

• Release engineering:

Coordination with release engineering is not required. A mass rebuild is not necessary for this change.

• Policies and guidelines:

Packaging guidelines should be updated to describe this process and the opt-out option, after the implementation is done.

• Trademark approval: N/A (not needed for this Change)

• Alignment with the Fedora Strategy:

This proposal aligns with Fedora’s strategy of improving contributor experience and easing workflows, supporting a more efficient and user-friendly ecosystem.

Upgrade/compatibility impact

This change will not affect the compatibility/upgrade.

Early Testing (Optional)

Do you require 'QA Blueprint' support? N

How To Test

Requesting a new repo in src.fedoraproject.org should result in pull request with Packit configuration being created for that repo.

User Experience

With this change, package maintainers will experience:

• Automated pull requests containing default Packit configuration files for newly created projects at src.fedoraproject.org.
• Clear explanations and instructions within the pull requests to help them understand the configurations and make necessary adjustments.
• The ability to quickly get started with Packit without needing to manually create configuration files.
• An opt-out option for those who prefer not to/can’t (their packages are not suitable for this kind of automation) use Packit.

Once the Packit configuration is merged, the release process will be almost fully automated. This includes:

• Opening pull requests for required updates when upstream releases occur.
• Performing Koji builds and Bodhi updates automatically after merging the updates by the maintainer.

This automation significantly reduces the repetitive workload for maintainers, allowing them to dedicate their time to improving package quality and addressing other critical aspects of their projects.

Dependencies

N/A

Contingency Plan

This feature is technically not really tight to the new Fedora version.

• Contingency mechanism: N/A
• Contingency deadline: N/A
• Blocks release? No

Documentation

There is no documentation for this yet, the work needed to be done by Packit maintainers is tracked in https://github.com/packit/packit-service/issues/2506. The documentation will be done as part of the work.