Add default annotations to Kubernetes build pods
What does this MR do?
This MR adds default annotations to Kubernetes build pods when the Kubernetes executor is used.
The following annotations are added by default:
| Key | Description |
|---|---|
job.runner.gitlab.com/id |
The ID of the job, unique across all jobs in the GitLab instance. |
job.runner.gitlab.com/url |
The job details URL. |
job.runner.gitlab.com/sha |
The commit revision the project is built for. |
job.runner.gitlab.com/before_sha |
The previous latest commit present on a branch or tag. |
job.runner.gitlab.com/ref |
The branch or tag name for which project is built. |
job.runner.gitlab.com/name |
The name of the job. |
project.runner.gitlab.com/id |
The project ID of the job. |
The list of annotations to be added is to be discussed.
I took inspiration from the current default docker executor labels. I think for most use cases the job_id and the project_id should be enough as they provide all the information to use the GitLab api for further queries based on the job. Additional annotations like job_sha could reduce api calls to GitLab if provided in this way.
The change is non-breaking, because default annotations are overwritten by annotations defined in the runner config via pod_annotations and by pod annotation overwrites defined in the job configuration.
Why was this MR needed?
Default pod annotations provide correct and unaltered information about build jobs via the Kubernetes api.
Pod annotations defined via the pod_annotations configuration in combination with variable expansion can be used to get some of the same information as Kubernetes annotations.
This approach does not work when the information must be reliable.
Users can overwrite predefined variables that would be used in annotations in their CI/CD configuration.
This makes it impossible to build systems or monitoring that need the annotations to be correct.
As an example use case; we use the job_id, project_id, job_name and job_sha to provide additional functionality to build jobs based on configuration files in the projects.
We use Kubernetes mutating admission webhooks to insert configurations into the pod manifest.
This needs the information to be unaltered so that jobs cannot "impersonate" other jobs.
What's the best way to test this MR?
I've added tests that verify that the pod manifest is build as expected and default annotations can be overwritten.
What are the relevant issue numbers?
#28767 is related as it proposes default annotations.