Skip to content

Resurrect and expand the Approvers(ci) scoped role #27697

@dudinea

Description

@dudinea

Summary

The Approver(ci) role exist in this project, but is not in use for a while.
It's ownership currently covers GitHub Actions workflows, CodeQL, Renovate/Dependabot configuration, and a small set of CI tool config files.

This proposal extends the scope of that role to include the full
build system — including the Makefile, container image definitions,
build and code-generation scripts, linter configuration, and release
tooling — by updating CODEOWNERS accordingly.

Motivation

1. Supply-chain attacks, third party infrastructure failures demands fast-reacting and available approvers.

GitHub Actions workflows, which are tightly coupled to the build
toolchain — including Makefile recipes, build scripts in hack/,
container image definitions, release configuration and various GitHub
repository configuration parameters represent a very high-value
supply-chain attack surface in the repository.

Responding to such threats requires contributors who understand all
these components, know various project's conventions as well as can
sufficiently understand project architecture, code and security
considerations to see how changes in the build system or project
dependencies can affect functionality and integrity of the software
components.

The project Leads and main Approvers, who mainly focus on the core
development tasks, may not be always available for dealing with the CI
and build system issues, and sometimes may even lack specialized
knowldge needed for such tasks.

A dedicated Approver(ci) role with enough permissions will make
make project more agile in hardening the CI infrastucture, dealing
with security updates, CI failures or security incidents.

2. High-volume dependency update throughput

Renovate and Dependabot generate a continuous stream of PRs that
update GitHub Actions versions, Go tool versions, base container
images, etc. These PRs are low cognitive overhead for someone who
understands the CI context but are distraction to the application
developers. Routing them to a dedicated CI approver team reduces
review latency and avoids burdening general approvers with work
outside their primary focus area.

4. Release pipeline ownership

The release process (GoReleaser configuration, release workflows,
version management, image signing, SBOM generation) is complex,
security-sensitive, and time-critical. It is natural for the people
who operate and evolve this pipeline to also have merge authority over
it, rather than always escalating to general approvers.

5. CI scope is uniquely file-addressable

Unlike "frontend" or "backend" code (which can be spread across many
packages and has fuzzy boundaries), the CI and build process scope
maps directly to a well-defined, stable set of files and directories.
CODEOWNERS can express this scope exhaustively with no ambiguity,
making it easy to enforce and audit.

Proposal

1. Update CODEOWNERS

Expand the existing CI section and add new entries to bring the full set of CI/build files under
@argoproj/argocd-approvers-ci co-ownership.

Current CI section

# CI
/.codecov.yml             @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.github/**               @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.goreleaser.yaml         @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/sonar-project.properties @argoproj/argocd-approvers @argoproj/argocd-approvers-ci

Proposed CI section

# CI
/.codecov.yml             @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.github/**               @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.goreleaser.yaml         @argoproj/argocd-approvers @argoproj/argocd-approvers-ci

# Build / e2e testing
Procfile                  @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
Makefile                  @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
Dockerfile                @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
Dockerfile.*              @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
.dockerignore             @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/Tiltfile                 @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/entrypoint.sh            @argoproj/argocd-approvers @argoproj/argocd-approvers-ci

# Security/code quality scanners/bots config
/.golangci.yaml           @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.codecov.yml             @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/.snyk                    @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/SECURITY-INSIGHTS.yml    @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/renovate.json            @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/renovate-presets/**      @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/sonar-project.properties @argoproj/argocd-approvers @argoproj/argocd-approvers-ci

# Assorted stuff in hack/ with exclusions for not CI/build related paths
/hack/                          @argoproj/argocd-approvers @argoproj/argocd-approvers-ci
/hack/gen-docs/                 @argoproj/argocd-approvers
/hack/migrate-gitops-engine/    @argoproj/argocd-approvers
/hack/gen-resources/            @argoproj/argocd-approvers
/hack/known_types/              @argoproj/argocd-approvers
/hack/admonitions-to-alerts.sh  @argoproj/argocd-approvers
/hack/generate-actions-list.sh  @argoproj/argocd-approvers
/hack/git-ask-pass.sh           @argoproj/argocd-approvers
/hack/git-verify-wrapper.sh     @argoproj/argocd-approvers

2. Update team description

Approver(ci) — Members may approve and merge pull requests whose
changed files fall entirely within the CI/build scope defined in
CODEOWNERS. Responsible for pipeline health, supply-chain
security of the build process, dependency updates, build system
maintenance, container image definitions, and release tooling.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions