Support `source_branch` as a trigger for copr jobs

[inknos]

Description

Hi, I would like to trigger copr builds for some specific PRs that we use to release our component.

What I am looking for is something like this:

  - job: copr_build
    trigger: commit
    targets:
      - fedora-all
    source_branch: 'name_of_pr_branch'

Our need is for specific PRs that we create before an upstream release. The problem is, we are changing the version number of our package, so we would also need to fix the version in the specfile, like this:

    actions:
      get-current-version:
        - bash -c 'rpmspec -q --queryformat "%{VERSION}\n" dnf5.spec | head -n1'

These prs are all done from a branch that is created just for release and deleted afterwards.

Benefit

With this feature we could conveniently run builds of the source code that we will release upstream and run our test suite before going in fedora. Currently we can only test PRs that don't update the version.

Importance

It's not a blocking issue, I would check the status of builds/tests from a previous PR but it's inconvenient and it can lead to errors.

Workaround

• [ ] There is an existing workaround that can be used until this feature is implemented.

Participation

• [ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

[mfocko]

I would probably go with extending the new require section, something like:

require:
  branch:
    source: …
    target: …

# or maybe
require:
  source_branch: …
  target_branch: …
# ^^^ I don't really like this though… especially if and when we extend the
# ‹require› section it will lead to “beefy” structures (as some already are)

( I guess both at the same time don't make sense though :) )

@lbarcziova wdyt?

p.s. it could probably also supersede the branch for commit trigger to have a bit more “sensible” and consistent config, that feels like a long-shot though :D

[inknos]

p.s. it could probably also supersede the branch for commit trigger to have a bit more “sensible” and consistent config, that feels like a long-shot though :D

yup that is something to address.

In my use case I am imagining something like this:

- job: copr_build # this will pass on the pr branch 
    trigger: commit
    targets:
      - fedora-all
    branch:
      source: 'pr_branch'
    actions:
      get-current-version:
        - bash -c 'rpmspec -q --queryformat "%{VERSION}\n" dnf5.spec | head -n1'
- job: copr_build # this will always fail on the pr_branch
    trigger: commit
    targets:
      - fedora-all
    branch: 'main' # supposedly defaults to branch>target

Which job should run? Should both jobs run even if I know that the second one will always fail on the pr_branch?

[lachmanfrantisek]

I would probably go with extending the new require section

@mfocko I quite like this idea since require also defines conditions. What Nicola suggests also makes sense:

    branch:
      source: 'pr_branch'

But I am probably for the following:

require:
  branch:
    source: …
    target: …

This looks the most consistent. Also for the reason branch is sometimes confused with Fedora branches.

[lbarcziova]

I like the suggestion of using require. But we should also take into consideration that as for the target branch, we already support for trigger: pull_request to have this configured via plain branch (see https://packit.dev/docs/configuration/upstream/copr_build#optional-parameters). However, I don't think many users use this, so we could help with changing the existing configs or deprecate this with the help of commit check warnings.