Restrict Release Tag Creation to Authorized Actors (Immutable Tag Governance)

[dcalavrezo-qorix]

What

Introduce strict governance for release tag creation across S-CORE repositories in order to:

• Prevent accidental or intentional re-pushing of release tags
• Protect immutability assumptions (e.g. devcontainer image tags)
• Improve traceability and release governance
• Support long-term reproducibility guarantees

Currently, in most repositories, committers can create tags and releases.

Since container images (e.g. ghcr.io/eclipse-score/devcontainer:v1.1.0) and other artifacts are often referenced by tag, tag mutability creates risk:

• Tags can be re-pushed
• A tag can silently point to different content over time
• Consumers referencing :vX.Y.Z may unknowingly receive different artifacts
• This breaks immutability assumptions and reproducibility guarantee

We already enforce strict tag blocking in bazel_registry using Otterdog:

newInfrastructureTeamRepo('bazel_registry') {
  rulesets+: [
    block_tagging(
      [
        "*",
      ],
      [
        "@eclipse-score/infrastructure-maintainers",
      ]
    ),
  ],
}

see change from @AlexanderLanin eclipse-score/.eclipsefdn@447b64e

How

Step 1 – Identify Scope

Determine which repositories publish:

• Container images (e.g. devcontainer)
• Toolchain artifacts
• Versioned releases consumed by other repos

Step 2 – Define Governance Policy

Identify the actors for each repo

Step 3 – Implement via Otterdog

Add rulesets similar to bazel_registry:

Step 4 – Optional: Release Workflow Enforcement

For stronger governance:

• Enforce releases via GitHub Action only
• Require PR + review before triggering release

Estimates for realization

Impact to Users of the Feature

• Stronger immutability guarantees
• Improved traceability
• Reduced risk of silent release modification
• Better foundation for reproducible builds

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[AlexanderLanin]

3 should also consider alternatives. e.g. can we restrict releases or only tags? What abpout github immutable releases, do we want that?