FIX GitHub action triggering for building image

[davidjeddy]

What does this PR do?

Version 1.1.1

Fix

• .github/workflows/build-and-push.yml manifest_build_and_push_on_feature no longer wrongs on tag creation
• .github/workflows/build-and-push.yml manifest_build_and_push_on_tag now correctly builds on tag creation

Test Plan

Merge to main, create tag via release process.

Have you read the Contributing Guidelines on issues?

yes

Summary by CodeRabbit

• Bug Fixes
  • Updated CI/CD pipeline configuration to properly build and push Docker manifests exclusively when code is tagged, preventing inadvertent builds during feature branch development and updates to the main branch.
  • Updated release documentation to note version 1.1.1 fixes to the continuous integration workflow.

[coderabbitai]

Warning

Rate limit exceeded

@davidjeddy has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 12 minutes and 21 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 85f1ffbb-0be9-4053-823d-c6338297e08f

📥 Commits

Reviewing files that changed from the base of the PR and between 5310589 and 1c81c7f.

📒 Files selected for processing (2)

• .github/workflows/build-and-push.yml
• CHANGES.md

📝 Walkthrough

Walkthrough

The pull request modifies the CI workflow to trigger manifest builds and pushes on tag creation instead of on main branch pushes, while preventing feature branches from triggering manifest operations. The CHANGES.md file is updated to document the fix and standardize section heading capitalization.

Changes

Cohort / File(s)	Summary
CI Workflow Conditions .github/workflows/build-and-push.yml	Refactored manifest job triggers: manifest_build_and_push_on_feature now excludes tag refs, and manifest_build_and_push_on_main renamed to manifest_build_and_push_on_tag with condition changed from main branch to tag refs trigger.
Changelog Documentation CHANGES.md	Added Version 1.1.1 entry documenting fixes to workflow manifest behavior; standardized section headings in Version 1.1.0 from plural to singular form (Fixes → Fix, Removed → Remove).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 With tags we dance, no more main's sway,
Manifests push when versions play,
Feature branches keep their peace,
Changelog tidied—the fixes increase! 🏷️

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing GitHub Actions workflow conditions to properly trigger manifest builds based on refs (tags vs feature branches).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch clo-4095-cve-maintenance-02

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR attempts to fix the GitHub Actions workflow so that manifest_build_and_push_on_feature does not trigger on tag creation, and a new manifest_build_and_push_on_tag job builds the manifest when a tag is pushed. However, the fix introduces critical bugs that prevent the intended behaviour from working.

Key issues:

• Tag job will never run: github.ref == 'refs/tags/*' performs a literal string comparison — the * is not treated as a wildcard in GitHub Actions if: expressions. No real tag ref (e.g. refs/tags/v1.1.1) will ever match this string, so manifest_build_and_push_on_tag is effectively dead code.
• Feature job still fires on tags: For the same reason, github.ref != 'refs/tags/*' will always be true for real tag refs, so manifest_build_and_push_on_feature will continue to run on tag creation — exactly the problem this PR aims to fix.
• Empty tag name on push-triggered builds: github.event.release.tag_name is only set on release events; for a plain tag push it will be an empty string, producing broken manifest commands. github.ref_name should be used instead.
• Main branch manifest job removed: The previous manifest_build_and_push_on_main job (for pushes to main) was removed and not replaced, so merges to main will no longer produce a manifest.

Confidence Score: 1/5

• Not safe to merge — the workflow fixes are logically broken and will result in no manifest being built on tag creation.
• Both condition expressions use unsupported glob syntax that will evaluate incorrectly: the tag job will never run, and the feature job will still fire on tags. The additional use of github.event.release.tag_name (which is empty on push events) compounds the problem. The PR does not achieve its stated goal.
• .github/workflows/build-and-push.yml requires all three if: condition and tag-name fixes before this is safe to merge.

Important Files Changed

Filename	Overview
.github/workflows/build-and-push.yml	Introduces two critical bugs: (1) glob patterns (refs/tags/*) are not supported in GitHub Actions if: expressions — the tag job will never run and the feature job will still fire on tags; (2) github.event.release.tag_name is empty on push-triggered tag builds. The previous manifest_build_and_push_on_main job was also removed without replacement.
CHANGES.md	Changelog updated to document v1.1.1 fixes and minor heading normalisation (Fixes → Fix, Removed → Remove). No issues found.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Git Push / Release Published] --> B{build_and_push\nmatrix: amd64 + arm64}
    B --> C{Evaluate github.ref}

    C -->|github.ref != refs/heads/main\nAND github.ref != refs/tags/*\nliteral comparison| D[manifest_build_and_push_on_feature\nTag: github.sha]

    C -->|github.ref == refs/tags/*\nliteral comparison — NEVER TRUE| E[manifest_build_and_push_on_tag\nTag: github.event.release.tag_name\nmay be empty on push events]

    C -->|github.ref == refs/heads/main\nNO JOB EXISTS| F[❌ No manifest job for main branch]

    style E fill:#f66,color:#fff
    style F fill:#f66,color:#fff
    style D fill:#fa0,color:#000

Loading

Comments Outside Diff (1)

1. .github/workflows/build-and-push.yml, line 81-87 (link)

   github.event.release.tag_name is empty on push events

   The workflow triggers on both push: (line 4) and release: [published] (line 5-6). The github.event.release.tag_name context variable is only populated for release events. When a tag is pushed directly (not via a GitHub Release), this value will be an empty string, causing:

   • docker manifest create ... : — tagging with an empty string
   • docker manifest push ... : — pushing with an empty string

   Both commands will either fail with an error or produce an unintended image tag.

   Consider using github.ref_name instead, which is always set to the tag name on any tag push or release event:

_{Last reviewed commit: 5310589}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/build-and-push.yml:
- Line 46: Replace the incorrect literal ref comparisons in the workflow
condition (the if expression shown using github.ref == 'refs/tags/*' and similar
checks) with checks that use github.ref_type and github.ref_name so tag vs
branch routing works across tag-push and release events; update the same pattern
in the other occurrences referenced (the blocks around the conditions currently
at lines 67-68 and 81-87) to use github.ref_type == 'tag' (or == 'branch') and
github.ref_name for the actual ref name instead of matching against
'refs/tags/*' or literal refs.

In `@CHANGES.md`:
- Line 7: In CHANGES.md update the 1.1.1 entry that currently reads
".github/workflows/build-and-push.yml manifest_build_and_push_on_feature no
longer wrongs on tag creation" by replacing the typo "wrongs" with a correct
verb such as "triggers" (or "runs") so the line reads e.g.
".github/workflows/build-and-push.yml manifest_build_and_push_on_feature no
longer triggers on tag creation"; locate the string "wrongs" in CHANGES.md and
make this one-word replacement.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ac69cf2f-0c87-47f2-a779-16b212611d8e

📥 Commits

Reviewing files that changed from the base of the PR and between b4fd48d and 5310589.

📒 Files selected for processing (2)

• .github/workflows/build-and-push.yml
• CHANGES.md