ELN scratchbuilds for rawhide PRs

[hroncok]

Description

Hi.

Zuul has the check-for-eln and eln-rpm-scratch-build jobs enabled on rawhide Pull Requests.

The purpose of the check-for-eln is to determine whether the package is part of ELN. When it is, the eln-rpm-scratch-build job is not skipped.

The purpose of the eln-rpm-scratch-build job is to submit an ELN scratchbuild.

Mainly, this serves as a way to verify that a package that is present in ELN still builds fine on ELN. Either because of some differences in the environment or because of the %rhel/%fedora conditionals in the spec file. This is useful when:

• Submitting a PR that changes some aspects of the build wrt ELN to verify such changes.
• Regression tests for all other PRs to avoid accidentally breaking the build for ELN.

Importance

This is a feature that is blocking us from stopping the use of Zuul.

Realistically, however, Zuul is unstable, and most of the time, this doesn't finish successfully.

A workaround is to submit such scratchbuidls manually -- but it's easy to forget, and I doubt many packagers would do that for regression testing.

Workaround

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

[hroncok]

@LecrisUT said:

Hmm I am thinking if I could make it as a tmt test since that would minimize the special code that packit would need to carry. Would a mock build also work for that?

Technically, a mock build would work, however, here are my concerns:

• Koji scratchbuilds are much easier to inspect.
• A mock build would probably only run on one architecture.
• A mock build might not behave 100% same as a Koji build. Hence, a problem might not be discovered before a PR is merged.
• A mock build might consume considerable resources on the CI infra (CPU+memory while building, storage to serve the built RPMs for inspection), while a Koji build runs in Koji and delegates this responsibility.

[hroncok]

As a future improvement, this could even run the rpminspect+rpmlint+custom tests on ELN based on the results. But that has never been available on Zuul.

[LecrisUT]

The difficulty of doing it through koji on tmt is that it would need some authentication. I think we can do it now with testing-farm secrets, but haven't tried it. Connecting it to the other jobs would be much more difficult, unless we hook it directly in packit-service as we do with the current scratch-build runs. I would be inclined towards this method for now until we can figure out some other interface.

As for the triggers, I suppose this would be triggered only on rawhide PRs?

[hroncok]

Yes, rawhide prs. Possibly also prs to eln branch, but I don't have a use case for that myself.

[nforro]

Possibly also prs to eln branch, but I don't have a use case for that myself.

That's covered by #2822.

[lachmanfrantisek]

Notes from the meeting today:

• We are able to check if the package is part of ELN and based on that we'll do this automatically. (We need to also check if a dedicated ELN branch is not present.)
• No configuration for now. This is a non-blocking status, so people shouldn't complain --- ideally, they should question the presence in ELN instead.
• Later, we can run more check on top of this build.

[lbarcziova]

Lists to check if package is part of ELN: https://tiny.distro.builders/view-all-source-package-name-list--view-eln.txt and https://tiny.distro.builders/view-all-source-package-name-list--view-eln-extras.txt.

If the conditions are met, separate task should be kicked off and reporting should be done via separate commit status.