Show or link to CI config for CI each Job

General
1

As CI configurations become more complex, I find identifying where a job was defined more important. We use included pipelines/jobs quite often which sometimes makes tracking down the CI config a chore. It would be really neat if on a CI Job it pointed to the .gitlabci.yaml file that defined the job. Especially when the .gitlabci.yaml is not in the repo. E.G. Compliance pipelines or an included pipeline.

Here is an example pipeline I was trying to follow for a debian package I wanted to build myself…

https://salsa.debian.org/ribalda/ugrep/-/jobs/4133156

I can’t for the life of me figure out where that job is defined, the root repo doesn’t even have a .gitlabci.yaml in it. I assume this is a compliance pipeline defined at the org level but IDK.

Anyhow our team uses included pipelines that can make it equally interesting to try and tack down where a job came from… especially if an included job overrides another job.

Anyone know if there is a way to do what I’m wanting for a particular job in a pipeline?

2

This could get easily out of hands, because you can override jobs in includes and you can have nested includes. So in theory a job can be defined in ci1.yaml which is included in ci2.yaml and overridden which is included in ci3.yaml and overridden again.

ci1.yaml:

job1:
  stage: test
  script:
    - echo hello
---
ci2.yaml:

include: 'ci1.yaml'

job1:
  image: ubuntu
  before_script:
    - echo before
---
ci3.yaml

include: 'ci2.yaml'

job1:
  image: debian
  script:
    - echo world

now in which “CI file” is the job configured?

Common approach is to name the jobs accordingly, so if your include is named “security” you could just name the job “security:job1”. Or use dedicated stages for included jobs.

EDIT: includes are always evaluated first, you can’t override local job with included one.

3

Agreed it can get out of hand, especially now with the compliance pipelines being triggered from outside your direct project. I think the answer should be that Gitlab keeps track of which thing overrode the other and then displays the source file in the job details and log view. Also we didn’t mention the ability to extend with templates. Having the ability to override and extend jobs etc. is a powerful way to make pipelines includable and modular within an organization, but it gets rather unwieldy when looking at a triggered pipeline. I think there should be a way to show where a thing is defined, even if it’s just a path/url to the file, and what rules triggered the job.

4

@dingus9

Welcome to the forum! There’s an open issue describing this type of functionality. It’s not currently scheduled. Feel free to comment with your use case and add a :+1: to show your support.

-James H, GitLab Product Manager, Analyze:Product Analtyics

5

I searched for a while trying to find such an issue, decided to run my thoughts here first before opening an issue. Thanks for pointing this one out!