Open lbarcziova opened 2 years ago
I would probably go with something like before
/after
, which might be quite versatile with respect to the desired pipeline, but definitely won't be the simplest to implement
What do we do when we add new job types that depend on each other and we'd suddenly get a tree? vm_image_build is definitely one: it could be tied to tests and rpm builds
I would probably go with something like
before
/after
, which might be quite versatile with respect to the desired pipeline, but definitely won't be the simplest to implement
I am worried that both options could be tricky to implement. But having after: other_job
would be really nice! Or use another job identifier as a trigger (what is actually the reality).
Just making noise that job referencing / ordering would be desirable for podman CI. A lot of our current cirrus workflow uses job dependencies. For example podman's success task.
I'm also looking at running 2 separate Makefile targets in 2 separate packit jobs with the second target depending on the first one in a podman-machine-os PR.
Since it is possible to add identifiers for jobs, we allow defining multiple Copr build jobs and multiple TF jobs. In that case, Packit Service doesn't know what Copr build job to use for the particular TF job.
For this purpose, we could introduce a new field for job configs which would allow the referencing, for example:
TODO: