Add API endpoint for pipeline bridge jobs
Related to #207226 (closed)
Problem statement
When using GET /pipelines/:id/jobs
, the response does not list any bridge jobs although the were created successfully.
Analysis
From #207226 (comment 291511965):
GET https://gitlab.example.com/api/v4/projects/123/pipelines/12345/jobs
: missingjob2
andjob3
and no reference to the created child-pipelines
- on missing
jobs2
andjobs3
, this occurs because those are "trigger" (also called "bridge") jobs and when we serialized jobs for a pipeline we only collect "normal" jobs (those that are executed by the Runner). I think this predates the notion of "trigger" jobs. Instead ofpipeline.builds
we should usepipeline.processables
to include everything. I'm not sure this classifies as ~bug if it was a miss or a feature if we had a reason for only returning runnable jobs.- on not serializing created child-pipelines: we should definitely render them and perhaps even inside the "trigger" jobs (currently missed) so it will be clear which job triggered which child pipeline.
☝ this could probably be an issue on its own and it's more complicated: for/pipelines/:id/jobs
we are using specific preloads and serializer forCi::Build
. This won't directly apply toCi::Bridge
jobs. We could create a new API endpointGET /pipelines/:id/bridges
that instead returns only bridge jobs. This means we could serialize them differently thanCi::Build
and even include a reference to the downstream pipeline.Otherwise a more complex solution would be to reuse
GET /pipelines/:id/jobs
and return a list of processables that can be eitherCi::Build
orCi::Bridge
. This is like returning polymorphic associations which has a set of complications (e.g. preloading:job_artifacts
won't work onCi::Processable
). I'm not sure we do that or discourage it. - cc @ayufan ?
Proposal
We could create a new API endpoint GET /pipelines/:id/bridges
that instead returns only bridge jobs. This means we could serialize them differently than Ci::Build
and even include a reference to the downstream pipeline.
- pros: very easy to implement
- cons: clients will need to call 2 endpoints to get all the jobs in a pipeline
old alternative proposal:
Including bridge jobs in the existing API endpoint is preferable although a bit more complex.
- Because we can't simply use
pipeline.processables
as we are preloading specific associations fromCi::Build
, we may need to do it differently. MaybeUNION
bothpipeline.builds
andpipeline.bridges
(to be created) each with their own preloaded associations - in
Entities::Job
serializer we expose job specific attributes (e.g. artifacts) and bridge specific attributes (e.g. downstream pipelines) based on the type
- pros: clients will get all jobs with a single API call, much like the UI
- cons: complex to implement on many fronts (query, serializers, schema)