Running packit as a service for forks

[LecrisUT]

It would be nice to have some configurable options that can override the .packit.yaml through the service so that packit can run on github forks and copr forks. E.g. the upstream might define:

jobs:
  - job: copr_build
    trigger: commit
    owner: "@upstream_group"
    project: CI
    branch: main

But on your fork you want to edit it to something like:

jobs:
  - job: copr_build
    trigger: commit
    owner: forking_user
    project: CI
    branch: develop_branch

Ideally you don't want to rebase back-and-forth so much just to enable this testing. It would be nice to have it editable in either the github app interface or via the packit cli such that you can add/replace jobs per repository.

Benefit:

• Allows to run CI jobs on individual users before submitting PRs
• Allows to create packit setup on forks that do not want to include this dependency upstream

[lachmanfrantisek]

Hi again!

It would be nice to have some configurable options that can override the .packit.yaml through the service so that packit can run on github forks

Regarding running the Packit itself, you need to install the GitHub action there as well. Otherwise we will not receive any events we can react to... So here, I don't think we need/can do anything.

Regarding the Copr project, it's not so easy. But a few notes:

• If you don't use explicit Copr projects, everything will work smoothly since upstream will use something like packit/namespace-project-pr-123 as a Copr repo, but fork packit/fork-project-pr-123.
• If you use explicit Copr project, fork won't be able to build anything there (if not allowed from the Copr settings). So, no harm should be done.
• So, the missing part is the project replacement when run from a fork. And TBH, I am really not sure if this is something that more people will use. Maybe, you can configure a build for any branch (by using a regex) with default project name so you don't need to overwrite anything.

[LecrisUT]

How about using some token values that can be defined per repo as secrets or environment? E.g. ${COPR_USER:-GITHUB_USER}. Unfortunately, that again does not appear to be accessible by github apps. Maybe have them be defined on packit side? For local users, it could be defined from ~/.config/packit and/or environment variables

[lachmanfrantisek]

Hi @LecrisUT !

We can discuss this together tomorrow, but the audience for this is really really small (nearly everyone uses purely upstream and doesn't need jobs to be run from a fork). And those that need this have a few options to do that -- using the default project names (managed by Packit) is really easy and suggested for PRs in general (one can use additional_repo for dependency use cases). You can also do quite a lot with branch builds and regexes.

(I am leaving discussions for config path and project variables in separate issues.)

So, unless we have a really clear use case we can't currently solve, I am going to close this issue.

[LecrisUT]

Hmm, can we at least document how one can run packit jobs with default project names on a fork when the original uses custom owner/project? Otherwise we are limited to jobs running only on PRs, which are also not properly gated atm.

[lachmanfrantisek]

Good point, let's add some examples to the example section: https://packit.dev/docs/configuration/examples/

[lachmanfrantisek]

Shortly for now:

• Ideally, you want to use default names if possible. That will manage the naming out of the box.
• If you can't do that, you can either define a second job with the default names. (Both will run both on upstream and downstream -- in upstream, the default ones will not be needed, in the fork, the one with the hardcoded project will fail for the permissions.
• Ideally, you want to improve the previous use case with a good branch name regex -- e.g. something like ^(?!main).* should help to run builds in Packit's project for the pushes to all non-main branches. (But someone needs to try it for real..;)