Use koji_build for scratch when koji_tags are present for tito #407
Conversation
ehelms
force-pushed
the
use-koji-build-scratch
branch
from
f2251dd to
15e9de7
Compare
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
ehelms
force-pushed
the
use-koji-build-scratch
branch
from
15e9de7 to
614710f
Compare
| "koji watch-task 1234", | ||
| "koji taskinfo -v 1234", | ||
| "koji build obaltest-nightly-el8 /tmp/SRPMs/hello-2.10-2.src.rpm --scratch", | ||
| "koji watch-task 1234" |
There was a problem hiding this comment.
Looks like it now builds multiple OSes sequentially. I think the same task ID is just a limitation of our stub implementation, but it can result in slower releases. Have you considered that?
The impact is probably limited for releases with just a single OS (EL9) but things like client could be slower.
There was a problem hiding this comment.
Correct and correct. This is how koji based builds have been working since it's implementation (e.g. https://github.com/theforeman/obal/pull/407/files#diff-659bad232c71219167252c1a5ccbc427b6f54925b78741df18613c3c49aaa4c1R170). This was a trade-off that had to be made to prevent making the code overly complex since there are multiple operations throughout the entire scratch or release process that happen such as checking on if a build exists, performing a build, grabbing the build results. The simplest way to do this is treat each package and OS combination as an entity and perform the set of operations. Ideally, one would then just "turn up" the parallelism in Obal at the Ansible level (https://github.com/theforeman/obal/blob/master/obal/data/playbooks/release/release.yaml#L5). From what we've seen in the past, what holds us back from that is Git annex that is acting on a single atomic git repository.
3 participants
This allows incremental switchover to koji/brew build from tito by allowing scratch builds to flow through koji_build if koji_tags are defined.