Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
Those new jobs have been configured to be triggered for Python3.x repositories. An example of PR that have triggered these jobs: [1]
See the wiki for more details: [2]
[1]: https://src.fedoraproject.org/rpms/python3.9/pull-request/30#comment-63513 [2]: https://fedoraproject.org/wiki/Zuul-based-ci#Supported_build_arch
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
Pierre
On 06. 01. 21 14:25, Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
In the future, possibly.
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
On Wed, Jan 06, 2021 at 14:39 Miro Hrončok wrote:
On 06. 01. 21 14:25, Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
In the future, possibly.
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
It seems like we could add a `check-for-arches` parent job, similarly to the `check-for-tests`, to selectively enable the extra arches job when the spec doesn't set the noarch.
Is there a cannonical command to run on a spec file to know if it is a noarch package?
-Tristan
On 06. 01. 21 16:17, Tristan Cacqueray wrote:
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
It seems like we could add a `check-for-arches` parent job, similarly to the `check-for-tests`, to selectively enable the extra arches job when the spec doesn't set the noarch.
Is there a cannonical command to run on a spec file to know if it is a noarch package?
I don't know.
This could be a way:
$ rpm --specfile python-six.spec python-six-1.15.0-3.fc33.noarch python2-six-1.15.0-3.fc33.noarch python3-six-1.15.0-3.fc33.noarch
$ rpm --specfile python-six.spec | rev | cut -d'.' -f 1 | rev noarch noarch noarch
If all lines say noarch, it is noarch.
But there are also excludearch statements etc. I wonder how Koji tells.
On Wed, Jan 06, 2021 at 04:31:47PM +0100, Miro Hrončok wrote:
On 06. 01. 21 16:17, Tristan Cacqueray wrote:
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
It seems like we could add a `check-for-arches` parent job, similarly to the `check-for-tests`, to selectively enable the extra arches job when the spec doesn't set the noarch.
Is there a cannonical command to run on a spec file to know if it is a noarch package?
I don't know.
This could be a way:
$ rpm --specfile python-six.spec python-six-1.15.0-3.fc33.noarch python2-six-1.15.0-3.fc33.noarch python3-six-1.15.0-3.fc33.noarch
$ rpm --specfile python-six.spec | rev | cut -d'.' -f 1 | rev noarch noarch noarch
If all lines say noarch, it is noarch.
But there are also excludearch statements etc. I wonder how Koji tells.
I don't know the logic koji uses per say but it works from the srpm not the spec file so there may be difference then.
Pierre
On Wed, Jan 06, 2021 at 16:44 Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 04:31:47PM +0100, Miro Hrončok wrote:
On 06. 01. 21 16:17, Tristan Cacqueray wrote:
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
It seems like we could add a `check-for-arches` parent job, similarly to the `check-for-tests`, to selectively enable the extra arches job when the spec doesn't set the noarch.
Is there a cannonical command to run on a spec file to know if it is a noarch package?
I don't know.
This could be a way:
$ rpm --specfile python-six.spec python-six-1.15.0-3.fc33.noarch python2-six-1.15.0-3.fc33.noarch python3-six-1.15.0-3.fc33.noarch
$ rpm --specfile python-six.spec | rev | cut -d'.' -f 1 | rev noarch noarch noarch
If all lines say noarch, it is noarch.
But there are also excludearch statements etc. I wonder how Koji tells.
I don't know the logic koji uses per say but it works from the srpm not the spec file so there may be difference then.
Alright, so we proposed a new job to define when to run the per-arch koji build here: https://pagure.io/fedora-zuul-jobs-config/blob/master/f/playbooks/rpm/check-...
And here is the PR (and it's depends-on) to enable this for the build template: https://pagure.io/fedora-zuul-jobs/pull-request/89
-Tristan
On 06. 01. 21 18:45, Tristan Cacqueray wrote:
On Wed, Jan 06, 2021 at 16:44 Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 04:31:47PM +0100, Miro Hrončok wrote:
On 06. 01. 21 16:17, Tristan Cacqueray wrote:
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
It seems like we could add a `check-for-arches` parent job, similarly to the `check-for-tests`, to selectively enable the extra arches job when the spec doesn't set the noarch.
Is there a cannonical command to run on a spec file to know if it is a noarch package?
I don't know.
This could be a way:
$ rpm --specfile python-six.spec python-six-1.15.0-3.fc33.noarch python2-six-1.15.0-3.fc33.noarch python3-six-1.15.0-3.fc33.noarch
$ rpm --specfile python-six.spec | rev | cut -d'.' -f 1 | rev noarch noarch noarch
If all lines say noarch, it is noarch.
But there are also excludearch statements etc. I wonder how Koji tells.
I don't know the logic koji uses per say but it works from the srpm not the spec file so there may be difference then.
Alright, so we proposed a new job to define when to run the per-arch koji build here: https://pagure.io/fedora-zuul-jobs-config/blob/master/f/playbooks/rpm/check-...
Careful with the exit code of grep -v:
$ echo -e 'x86_64\nnoarch' | grep -v noarch x86_64 $ echo $? 0
And here is the PR (and it's depends-on) to enable this for the build template: https://pagure.io/fedora-zuul-jobs/pull-request/89
On 1/6/21 5:39 AM, Miro Hrončok wrote:
On 06. 01. 21 14:25, Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
In the future, possibly.
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
Can we disable simple-koji-ci for packages with zuul enabled? Currently, when I create a PR for LLVM, it triggers 3 scratch builds (simple-koji-ci, zuul, CI tests), and this seems unnecessary to me.
-Tom
On Wed, Jan 06, 2021 at 07:27:54AM -0800, Tom Stellard wrote:
On 1/6/21 5:39 AM, Miro Hrončok wrote:
On 06. 01. 21 14:25, Pierre-Yves Chibon wrote:
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be triggered at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
In the future, possibly.
The problem now is that you need to opt in for this and it does not know how to recognize a noarch package yet. So if we enable this for all packages, we would waste resources (I mean, it is certainly a good idea to verify a noarch package builds on all architectures, but not sure if all the time).
Can we disable simple-koji-ci for packages with zuul enabled? Currently, when I create a PR for LLVM, it triggers 3 scratch builds (simple-koji-ci, zuul, CI tests), and this seems unnecessary to me.
Not currently, there is a reason that simple-koji-ci starts with "simple" ;-)
Pierre
Hi,
On Wed, Jan 6, 2021 at 1:25 PM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Jan 06, 2021 at 01:20:26PM +0000, Fabien Boucher wrote:
Hi,
I'd like to introduce a recent change to Fedora Zuul CI.
Some packagers raised the need to get CI feedback for builds on supported architectures.
So we have defined in Zuul some jobs that can be configured to be
triggered
at PR's creation and update.
rpm-scratch-build-aarch64 rpm-scratch-build-armhfp rpm-scratch-build-i386 rpm-scratch-build-ppc64le rpm-scratch-build-s390x
If we configure these to run for every single PR opened on dist-git, could we then retire simple-koji-ci? (Or should we merge simple-koji-ci into a zuul-based CI?)
Today we run the Zuul CI on a small set of distgits repositories (~300). We are planning to attach more distgits at regular basis. So It seems we are far from the simple-koji-ci coverage. Do we have a the list of distgits repos where simple-koji-ci is attached ? Or is simple-koji-ci attached to all Fedora's distgits ?
On 07. 01. 21 10:05, Fabien Boucher wrote:
Do we have a the list of distgits repos where simple-koji-ci is attached ? Or is simple-koji-ci attached to all Fedora's distgits ?
All.
-
Fabien Boucher -
Miro Hrončok -
Pierre-Yves Chibon -
Tom Stellard -
Tristan Cacqueray