Builds on excluded architectures should be given a result other than 'Failed'

[fedora-copr-github-bot]

Original issue: https://pagure.io/copr/copr/issue/2137
Opened: 2022-03-23 22:56:40
Opened by: tstellar

Currently if you build a package with ExclusiveArch or ExcludeArch, the build will be marked as Failed for chroots with the excluded architecture. It would be nice if these builds would be given a different result, like skipped, for example.

---

praiskup commented at 2022-03-24 15:04:47:

Thank you for the report. Do you have a link to such a build?

---

tstellar commented at 2022-03-24 17:10:37:

I have two examples highlighting the different failure modes:

https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/clang-built-f36/build/3714972/
This build fails to install some required packages, because they don't exist for the architecture.

https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/clang-built-f36/build/3714957/
This build installs all the dependencies, but then fails to start the build with the error "Architecture is not included"

[praiskup]

See also #2548, and https://bugzilla.redhat.com/show_bug.cgi?id=2171323

[opoplawski]

This would be greatly appreciated. It's really quite easy to reproduce:

• create a copr with all the different arches
• Build a package with ExcludeArch or ExclusiveArch

[xsuchy]

From a discussion with @tstellar : For every run we do, we end up spending time filtering these false failures out of our results.
I want to reevaluate the priority on the next triage.

[praiskup]

We should contact the Tools team and ask for the requirements on this feature.

[FrostyX]

As I see it, there are two approaches that we can choose from:

1. When we build SRPM and download it from a builder to backend, we can query its %{EXCLUSIVEARCH}, and limit its chroots in a similar fashion that chroot_denylist does. There are two issues:
   • chroot_denylist is currently implemented on Package level, not Build level, so we can't use it directly
   • Is it safe to query the information on backend? I guess it is.
2. Build the package in all enabled chroots and query the exclusive arch value in copr-rpmbuild and compare it to the chroot we are currently building in. Then possibly stopping the build immediately and letting backend know that it was skipped because of the exclusive arch. The problem is that copr-rpmbuild would probably have to return this information via an exit code, which would be a new precedent. So far it is only 0 and non-zero as a general failure.

Leaving it here for future implementation, I'd use this code to query the exclusive architectures:

import rpm
ts = rpm.TransactionSet()
with open(path, "rb") as rpm_fd:
    pkg = ts.hdrFromFdno(rpm_fd)
    archs = pkg["exclusivearch"]

[tstellar]

Does this query still work if the spec file uses ExcludeArch instead of ExclusiveArch ?

[praiskup]

How Koji does this? Koji somehow filters the list of architectures using Ex*Arch.

[praiskup]

Option 1 seems better to me. Ad Is it safe to query the information on backend? I guess it is. - should be, but for extremely new RPM features in new chroots problems might happen (but similar problem might happen on builder). I think we should do this on builder anyway, e.g. for BuildChroot builds we already have the results.json concept that we could now use for source builds?

[xsuchy]

How Koji does this? Koji somehow filters the list of architectures using Ex*Arch.

https://pagure.io/koji/blob/master/f/koji/__init__.py#_1178

And then koji.get_header_fields(srpm, ['arch']

Also, mind https://pagure.io/koji/issue/19

[praiskup]

The #1701 added the python-specfile into the copr-backend.spec, and I don't quite feel this is ideal.
Would you @FrostyX mind moving that (spec / SRPM analysis from backend to builder, and create the
results.json or alike for SRPM builds? (similar to what we have for BuildChroot handling)