decouple internal testing farm tasks

[lsm5]

This way non-internal testing farm tasks don't have to wait on approval from someone with commit access to the repo. Especially useful for update PRs created by Renovate.

The integration tests run on the internal testing farm are linked to this new build job using the same identifier integration_test_internal.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[lsm5]

I guess this can only be verified after it's merged and renovate or a non-committer creates a PR. Also, this change should not create rpm-build:fedora-* tasks but right now they are getting created because of packit/packit-service#2131 .

[lsm5]

@Luap99 PTAL

[Luap99]

There seems to be a bunch of duplicated tasks for the rpm-build tasks now??

[lsm5]

There seems to be a bunch of duplicated tasks for the rpm-build tasks now??

@Luap99 the ones for epel are expected, we need a separate build job for use by internal testing farm jobs. The duplicated tasks for fedora are being tracked in the packit issue.

[Luap99]

But we do need twice the same job? IS there no way to make it only build once and have the RHEL task consume the right build?

Doing the exact same thing twice is totally wasting resource increasing odds for flakes and totally confusing when looking at this job list.

[Luap99]

Or maybe asking the other way around, couldn't we drop the existing build taks then? I feel like I missing how this is supposed to work.

[baude]

what say you @lsm5

[lsm5]

This can be closed. With the merging of #458 , the fedora jobs at least should run for all PRs regardless of the PR submitter being maintainer / outside contributor. I suspect the centos 9 jobs should run the same way as fedora jobs and only rhel9 jobs will need a maintainer to trigger them. Guess we'll find out in upcoming PRs. Worst case, a maintainer can trigger them all.

[Luap99]

@lsm5 yes it seems to work if I look at #456