Skip to content

Check Trivy DB age for all major versions

Oscar Tovar requested to merge otovar/check-all-db-ages into master

What does this MR do?

The latest tag cannot be used to check the db-age for the latest maintained version. This is because it points to the last major version image that was pushed. For example, one day you can get a version latest that points to a new build of v7, but the next day another that points to v6.

This non-determinism means that the person on reaction rotation to know that the build pipeline may fail, but the db-age pipeline to pass. For consistency, this MR changes the db check to happen on all major versions we build for - 5, 6, and 7. If this is not desired, then we can change this to only check for v7.

Pipeline examples:

Pipeline #1

In this pipeline, the v6 finishes last, so the latest tag points to the v6 image.

v7 trivy:latest

{
  "id": 6924608446,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [Dockerfile]",
  "ref": "7.3.1",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-23T16:02:03.623Z",
  "started_at": "2024-05-23T16:16:35.272Z",
  "finished_at": "2024-05-23T16:17:46.129Z",
  // ...
}

v6 trivy:latest

{
  "id": 6924608176,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [trivy, Dockerfile]",
  "ref": "6.7.2",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-23T16:02:00.258Z",
  "started_at": "2024-05-23T16:18:40.453Z",
  "finished_at": "2024-05-23T16:19:45.079Z",
  // ...
}

v5 trivy:latest

{
  "id": 6924607779,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [trivy, Dockerfile]",
  "ref": "5.5.9",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-23T16:01:57.102Z",
  "started_at": "2024-05-23T16:15:18.594Z",
  "finished_at": "2024-05-23T16:16:29.936Z",
  // ...
}

Pipeline #2

In this pipeline, the v5 job finishes last, so the latest tag points to the v5 version of the image.

v7 trivy:latest

{
  "id": 6914408836,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [Dockerfile]",
  "ref": "7.3.1",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-22T16:01:42.918Z",
  "started_at": "2024-05-22T16:13:57.362Z",
  "finished_at": "2024-05-22T16:15:05.368Z",
  // ...
}

v6 trivy:latest

{
  "id": 6914408048,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [trivy, Dockerfile]",
  "ref": "6.7.2",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-22T16:01:40.273Z",
  "started_at": "2024-05-22T16:17:09.602Z",
  "finished_at": "2024-05-22T16:18:13.836Z",
  // ...
}

v5 trivy:latest

{
  "id": 6914407096,
  "status": "success",
  "stage": "release",
  "name": "tag latest: [trivy, Dockerfile]",
  "ref": "5.5.9",
  "tag": true,
  "coverage": null,
  "allow_failure": false,
  "created_at": "2024-05-22T16:01:37.309Z",
  "started_at": "2024-05-22T16:12:16.583Z",
  "finished_at": "2024-05-22T16:13:25.711Z",
  // ...
}

What are the relevant issue numbers?

Related to No Notifications for Failed Scheduled Pipelines (gitlab-org/gitlab#36806) • Veethika Mishra • Backlog This surfaced because we didn't know why the pipeline didn't run. It turned out that the permissions for the scheduled pipeline owner had changed, and this started to silently fail.

Does this MR meet the acceptance criteria?

Edited by Oscar Tovar

Merge request reports