Implement job referencing

[lbarcziova]

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:

- job: copr_build
  identifier: "build1"
  trigger: pull_request
  actions: ...

- job: copr_build
  identifier: "build2"
  trigger: pull_request
  actions: ...

- job: tests
  identifier: "tests2"
  trigger: pull_request
  build_identifier: "build1"

- job: tests
  identifier: "tests2"
  trigger: pull_request
  build_identifier: "build2"

TODO:

• [ ] discuss the design with team (including the naming :D)
• [ ] implement
• [ ] properly document it

[mfocko]

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

[TomasTomecek]

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

[lachmanfrantisek]

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).

[lsm5]

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.