Automate updating action.yml image tag on new major version release

[jmeridth]

Problem

When a new major version tag is created (e.g., v2, v3), the Docker image tag in action.yml needs to be updated to match. Currently this is a manual step that could be forgotten.

The action.yml currently references:

image: "docker://ghcr.io/github-community-projects/contributors:v1"

When users reference github-community-projects/contributors@v2 in their workflows, GitHub reads action.yml from that git ref. So action.yml must say :v2 in the commit that the v2 tag points to — updating it after the tag is created means the tag points to a commit with the wrong image reference.

Options

Option A: Post-release workflow job that updates action.yml and moves the tag

Add a job to the existing release workflow that runs after release_image. It would update action.yml, commit to main, and force-move the tag to the new commit.

Pros:

• Fully automatic, lives in the existing release workflow
• Uses the short-tag output that the reusable workflow already provides

Cons:

• Moving tags is messy — anyone who already fetched the tag gets stale refs
• Requires contents: write to force-push a change to action.yml to the new major short-tag.
• Small window where the tag exists but points to the wrong commit

Option B: Pre-release CI check + manual update

Add a validation step to PR CI that checks if the image tag in action.yml is consistent. When doing a major version bump, the maintainer updates action.yml in the PR before the release is created.

Pros:

• Simple, no tag-moving needed
• action.yml is correct before the release happens

Cons:

• Requires the maintainer to know to update it manually
• CI check would need a way to know the "expected" version, which is difficult to derive automatically

Option C: Post-release workflow opens a PR

A separate workflow triggered by release: published that detects a new short-tag, opens a PR to update action.yml, and the maintainer merges before pointing users at the new major version.

Pros:

• Clean, reviewable, no force-moving tags

Cons:

• Window where the tag exists but action.yml is stale
• Requires a follow-up tag move or second release after merge

Recommendation

Option A is likely the most practical. Major version bumps are rare events, and the window between the initial tag and the moved tag is seconds within the same workflow run. The reusable workflow already outputs short-tag, so all the necessary data is available.

Option B is not a good option.

Option C is the cleanest because we ensure we get a review but the downside is there is a window of possible incorrect usages of action.yml with the old major tag.

[jmeridth]

@zkoppert Option A is easy and what I've done in the past but Option C allows for review and doesn't have an "auto-commit". Wdyt? I'll PR Option A and await your thoughts.

[zkoppert]

Option A sounds good to me.

[vchrombie]

Option A would be the perfect choice!