On Tue, Feb 9, 2021 at 4:29 PM Pierre - Yves Chibon
<pingou@fedoraproject.org> wrote:
> On Tue, Feb 09, 2021 at 03:35:11PM +0100, Miro Hrončok wrote:
> > On 09. 02. 21 15:27, Tom Stellard wrote:
> > > Has there been any more discussion about disabling simple-koji-ci on
> > > packages with Zuul enabled?
> >
> > It's generally disabled AFAIK. Or broken. Same outcome.
>
> AFAIK it's still running. Happy to decommission it though.
I think in one pull request, I saw simple-koji-ci being able to
generate the source tarball (presumably from the Source: URL) -> SRPM
-> start the build even when the tarball hadn't yet been uploaded to
the lookaside cache. Fedora CI wasn't able to do that at that time
(probably still can't) and Zuul CI wasn't enabled on that repo back
then.
Was I just imagining things or does simple-koji-ci really have that
feature? If yes, does/will Zuul CI provide the same?
I can't say for simple-koji-ci, but regarding Zuul the default jobs workflow is:
1: rpm-scratch-build: build a srpm from the PR, submit the srpm to Koji to run a scratch build,
finally store the built rpms in a public storage
Once 1 is finished, and in parallel:
2: rpmlint: run rpmlint command on built rpms
3: rpminspect: run rpminspect command on built rpms
4: rpm-install-test: install the built rpms on the target system
5: rpm-test (if STI tests inside the PR/distgit): run the STI tests
In addition, if the package produces architecture specific binaries, then Zuul runs additional
scratch-build jobs such as rpm-scratch-build-[s390x, ...], that are skipped if fully noarch.
This can be seen here [1] and here [2].