Skip to content

Submitting for review

There is no submit button. The pipeline opens the review merge request itself once the conditions are met, and your job is to make sure they are.

The conditions

  1. The pipeline run is on a Git tag.
  2. Every scan in that run passed.
  3. No hard gate failed.
  4. Every mitigations entry is written. None is empty or reads "Mitigation pending".

When all four are true, the pipeline opens a review merge request in the security repository. The source branch is named after the container, the project id, and the scan pipeline id, and the merge request description carries the CVE table with your justifications so the reviewer can read them in place.

What you see

The situation line on your container page changes to Submitted, with the merge request number and a link to it in GitLab. The five step strip shows the review MR as open. There is nothing further for you to do until the reviewer acts.

What the reviewer does

The reviewer claims the container, opens each finding, reads your justification alongside the evidence, and records a decision with a written reason. One of two things then happens.

If the build is authorized, the reviewer approves the merge request in GitLab under their own account. The approval is the authorization. Merging is a separate step for your team, and the merge request stays open until someone merges it. Merging promotes the scan record from the branch to main.

If the build is rejected, the reviewer closes the merge request and posts their reason as a note. Your container page shows that reason under SCA feedback, exactly as they wrote it. Address it, push, run the scans on a new tag, and a new merge request opens.

Merging

Once the merge request is approved, merge it in GitLab. Your pipeline then continues and the deliver stage publishes the image. Merging needs Developer access or above on the security repository; if you are not sure who has that, ask your reviewer.

Resubmitting

A rejection is a specific request for a change, not a mark against the build. Read the reason, make the change, and resubmit. The second review starts from what changed rather than from scratch, and a container that has not changed is recognized as unchanged. See Reviewing an unchanged container again.