GitLab-CI Job Ownership
Release notes
In the same line of ideas as the CODEOWNERS
file, the ownership of more fine grained object is often required, but impossible to achieve with this file. CODEOWNERS
will match files and directories, and users sometimes need something more granular. This when Job Ownership enters, to set ownership of GitLab-CI jobs, and manage related approvals.
Problem to solve
CODEOWNERS
works only on files, not on GitLab-CI jobs. While we could ask our users to isolate the jobs they want to cover with CODEOWNERS
, it doesn't prevent other changes in other files to potentially impact these jobs. Any modification of their behavior should be approved by the team responsible of them.
Intended users
- Cameron (Compliance Manager)
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Presley (Product Designer)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Rachel (Release Manager)
- Alex (Security Operations Engineer)
- Simone (Software Engineer in Test)
- Allison (Application Ops)
- Priyanka (Platform Engineer)
- Dana (Data Analyst)
- Eddie (Content Editor)
User experience goal
The user should be able to create a job to create dynamic approvals in case one or more jobs under a team responsibility is updated.
Proposal
This feature requires two other features non-existing today:
- A flat, compiled version of the GitLab-CI configuration as JSON
- The ability to add required approvals dynamically from the pipeline
graph LR
E(GitLab-CI expose config) -->|.gitlab-ci.json| J
J[Compare with previous version] -->|Diff| D{Job definition changed}
D -->|Yes| RA(Request Approval)
D -->|No| P[Pass]
Further details
Permissions and Security
- Add expected impact to members with no access (0)
- Add expected impact to Guest (10) members
- Add expected impact to Reporter (20) members
- Add expected impact to Developer (30) members
- Add expected impact to Maintainer (40) members
- Add expected impact to Owner (50) members
Documentation
This is not a feature per se, more a combination of other features with some custom code. But we can still document this along with https://docs.gitlab.com/ee/user/project/code_owners.html
Availability & Testing
We can create a job that will unit test changes on mocked gitlab-ci.json
files.
What does success look like, and how can we measure that?
I'm creating this issue because the GitLab AppSec team would like to be involved when secure jobs are updated, directly, or indirectly (using global defaults for example).
What is the type of buyer?
Is this a cross-stage feature?
Not really. The perimeter of this feature is just the job comparing the versions of the GitLab-CI configuration, and generating a report requesting approvals. Nothing the AppSec can't handle directly.