Skip to content

Add gitlab-bot to CODEOWNERS

Alessio Caiazza requested to merge gitlab-🤖-codeowners into master

What does this MR do and why?

Delivery Orchestration is testing a future-proof process to merge security changes back into canonical at the end of the security release process.

The main goal is to no longer have to run git operations in CI to complete the sync but to make use of GitLab merge requests from the forked security mirror.

The end goal is described in the following diagram, where we also see that this solution is not subject to master-branch contention, compared to the current approach, where merging a MR at the same time can break the process.

sequenceDiagram
    actor rm as Relese Manager
    participant rt as release-tools
    participant gl as gitlab.com
    participant ops as triage-ops
    participant runner
    actor Maintainer
    rm->>rt: Sync security default branch

    par Release Process
    rt->>+gl: API merge sercurity:master->canonical:master
    gl-->>rt: created gitlab-org/gitlab!5555
    and Development Process
    Maintainer->>+gl: Merge gitlab-org/gitlab!12345
    gl-->>-Maintainer: merged
    end

    runner->>+gl: pick a job
    note right of runner: no-op single job pipeline
    gl-->>-runner: single job for gitlab-org/gitlab!5555

    activate runner
    gl->>+ops: mergerequest.opened gitlab-org/gitlab!5555
    ops->>gl: approve gitlab-org/gitlab!5555
    ops->>gl: set auto-merge gitlab-org/gitlab!5555
    ops-->>-gl: done

    runner->>gl: job completed
    deactivate runner

    gl->>gl: auto-merge

    deactivate gl
    
    rm->>rt: Very mirroring status

We are well aware that this merge request is giving this bot the power to approve every code change. To counterbalance that, we are implementing a reactive triage-ops processor that audits every approval from the @gitlab-bot and immediately retracts approvals from changes that are not designed for this workflow gitlab-org/quality/triage-ops!2310 (merged)

It is also very important to mention that the merge requests we approve with this workflow only contain changes from the security mirror, which have already been reviewed (also by AppSec), tested, and deployed.

Related to gitlab-com/gl-infra/delivery#19460

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Alessio Caiazza

Merge request reports