Skip to content

Use build.yaml for release configuration in CI workflows#325

Open
guicassolato wants to merge 2 commits into
mainfrom
use-build-yaml-for-release-config
Open

Use build.yaml for release configuration in CI workflows#325
guicassolato wants to merge 2 commits into
mainfrom
use-build-yaml-for-release-config

Conversation

@guicassolato

@guicassolato guicassolato commented Jun 20, 2026

Copy link
Copy Markdown
Collaborator

Problem

The build-images-branches.yaml workflow currently passes hardcoded values (VERSION=0.0.0, AUTHORINO_VERSION=latest) to the base workflow. This causes issues for branches targeting release branches (e.g., backport branches for patch releases) because:

  1. The hardcoded versions don't match what's committed in the branch
  2. make verify-manifests and make verify-bundle fail in CI because manifests are generated with different versions than what's committed
  3. Release branches need to use specific versions, not 0.0.0 and latest

Solution

Enable the Makefile and CI workflows to read release configuration from build.yaml when present:

  • For dev branches (no build.yaml): Falls back to defaults (0.0.0, latest) - no change in behavior
  • For release branches (has build.yaml): Automatically uses the correct versions from build.yaml

Changes

Makefile

  • Reads VERSION, AUTHORINO_VERSION, and CHANNELS from build.yaml if file exists
  • Uses grep/sed for parsing (no yq dependency needed at variable definition time)
  • Includes whitespace trimming for robustness
  • Falls back to git SHA and 'latest' when build.yaml doesn't exist

GitHub Workflow (build-images-branches.yaml)

  • Adds detect-config job to extract configuration from build.yaml
  • Passes extracted values to build-images-base workflow
  • Falls back to 0.0.0/latest when build.yaml not found

Alternative Considered

Commit build.yaml in main with default values (VERSION=0.0.0, AUTHORINO_VERSION=latest, etc.) and simplify the Makefile to always read from the build file without fallback logic.

This alternative was discarded for now to make the change less disruptive - build.yaml continues to only exist in release branches. However, we're open to revisiting this decision in the future if having a committed build.yaml in main proves beneficial.

Benefits

  • ✅ Release/backport branches can use build.yaml to set correct versions automatically
  • ✅ CI verification passes because generated manifests match committed ones
  • ✅ No change for dev branches (maintain current behavior)
  • ✅ Cleaner than environment-specific workarounds

Testing

  • ✅ Tested on release backport branches (v0.23.3, v0.24.1, v0.25.1)
  • ✅ Variable extraction works correctly with whitespace trimming
  • ✅ Falls back gracefully when build.yaml doesn't exist

Developed while preparing patch releases v0.23.3, v0.24.1, and v0.25.1

Contains commits of #326, which should be merged first for a clean history.

Summary by CodeRabbit

Summary by CodeRabbit

Release Notes

  • Chores
    • Improved build infrastructure by detecting build parameters from build.yaml when present, including versioning and release channel defaults, with sensible fallbacks when the file is missing.
    • Updated branch image builds to use these dynamically detected values and tightened registry credential passing.
    • Enhanced the Makefile to derive release-related variables from build.yaml, defaulting channels to stable when unset.

@coderabbitai

coderabbitai Bot commented Jun 20, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The PR adds build.yaml-driven configuration to both the Makefile and the branch-build GitHub Actions workflow. The Makefile parses build.yaml at variable-definition time to supply VERSION, AUTHORINO_VERSION, and CHANNELS defaults. The CI workflow gains a detect-config job that reads the same file and passes the extracted values into the reusable build workflow, whilst replacing inherited secrets with an explicit allow-list of registry credentials.

Changes

build.yaml-driven build configuration

Layer / File(s) Summary
Makefile build.yaml variable defaults
Makefile
Defines BUILD_CONFIG_FILE, parses version and authorinoVersion from build.yaml into BUILD_CONFIG_VERSION and BUILD_CONFIG_AUTHORINO_VERSION, updates VERSION default precedence to prefer the parsed version before falling back to the git SHA, sets AUTHORINO_VERSION from build.yaml when unset, defaults CHANNELS to stable when build.yaml version is present, and removes the duplicate BUILD_CONFIG_FILE assignment.
CI detect-config job and build-branches wiring
.github/workflows/build-images-branches.yaml
Adds a detect-config job that parses build.yaml with shell fallbacks and exports job outputs; updates build-branches to depend on detect-config and consume its outputs (operatorVersion, authorinoVersion, relatedImageAuthorino, channels, defaultChannel) instead of hard-coded values, and replaces secrets: inherit with an explicit allow-list of registry credentials.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 Hop, hop — no hard-coded strings to-day,
A build.yaml shows the way!
The Makefile reads with grep and sed,
The workflow job detects ahead.
Channels default, versions align —
This rabbit thinks the config's fine! ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically summarizes the main change: adopting build.yaml for release configuration in CI workflows, which directly addresses the PR's core objective of fixing version mismatch issues.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch use-build-yaml-for-release-config

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

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

@guicassolato guicassolato self-assigned this Jun 20, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build-images-branches.yaml:
- Line 53: Replace the blanket `secrets: inherit` statement with explicit secret
mapping that only passes the specific secrets required by the reusable workflow.
Instead of inheriting all available secrets, use the `secrets` key to map
individual secrets by name (such as `SECRET_NAME: ${{ secrets.SECRET_NAME }}`)
for each secret that the downstream workflow actually needs, following the
principle of least privilege.
- Around line 11-13: The detect-config job lacks an explicit permissions block,
which causes it to inherit broad default token scopes. Add a permissions: block
at the job level under detect-config that specifies only the minimal required
permissions for this workflow's operations. Review what actions and steps the
detect-config job performs to determine which specific permissions it actually
needs (such as contents, id-token, etc.) and declare only those in the
permissions block, following the principle of least privilege.
- Around line 21-22: The actions/checkout step is using a version tag reference
without a commit SHA, which weakens supply-chain security. Update the checkout
action to pin to a specific commit SHA instead of `@v4`, and add the
persist-credentials option set to false since this step only performs a
read-only checkout operation that does not require credential persistence.
- Around line 33-34: The CHANNELS and DEFAULT_CHANNEL environment variables in
the build-images-branches.yaml workflow are hardcoded to "stable" instead of
being dynamically read from the build.yaml configuration file. To fix this,
replace the hardcoded string values for CHANNELS and DEFAULT_CHANNEL with
dynamic values that are parsed and extracted from the build.yaml configuration
file, ensuring that channel configuration is actually driven by the config file
rather than bypassing it with static values.
- Around line 30-32: The grep and sed pipeline in the OPERATOR_VERSION,
AUTHORINO_VERSION, and AUTHORINO_IMAGE variable assignments succeeds with empty
output when fields are missing, preventing the fallback values from being
applied. Restructure each variable assignment to explicitly check if the
extracted value is empty and use the fallback only when the result is empty. For
example, use parameter expansion or a conditional check to ensure that when grep
finds no matching version key, authorinoVersion key, or authorinoImage key in
the BUILD_FILE, the corresponding default values (0.0.0, latest, and
quay.io/kuadrant/authorino:latest) are used instead of empty strings.

In `@Makefile`:
- Around line 35-36: The VERSION variable is being assigned on line 35 even when
BUILD_CONFIG_VERSION is empty, which prevents the fallback to git SHA on line 36
from executing since VERSION is already set. Replace the two separate VERSION
assignments with a single assignment that conditionally uses
BUILD_CONFIG_VERSION if it is not empty, otherwise falls back to the git SHA
using make's conditional syntax such as the if function, for example: VERSION ?=
$(if $(BUILD_CONFIG_VERSION),$(BUILD_CONFIG_VERSION),$(shell git rev-parse
HEAD)).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ad1a5602-d98a-4597-a687-bb1ceb100d80

📥 Commits

Reviewing files that changed from the base of the PR and between 127fc24 and b5fcb9e.

📒 Files selected for processing (2)
  • .github/workflows/build-images-branches.yaml
  • Makefile

Comment thread .github/workflows/build-images-branches.yaml
Comment thread .github/workflows/build-images-branches.yaml Outdated
Comment thread .github/workflows/build-images-branches.yaml Outdated
Comment thread .github/workflows/build-images-branches.yaml Outdated
Comment thread .github/workflows/build-images-branches.yaml Outdated
Comment thread Makefile Outdated
@codecov-commenter

codecov-commenter commented Jun 20, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.20%. Comparing base (d3dc069) to head (7a17cac).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #325   +/-   ##
=======================================
  Coverage   57.20%   57.20%           
=======================================
  Files          13       13           
  Lines        1458     1458           
=======================================
  Hits          834      834           
  Misses        529      529           
  Partials       95       95           
Flag Coverage Δ
unit 57.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@guicassolato guicassolato force-pushed the use-build-yaml-for-release-config branch from b5fcb9e to be0c3ab Compare June 20, 2026 17:01
Replaces the make/release.mk approach with reading configuration from build.yaml.
This makes build.yaml the single source of truth for release configuration.

Changes:
- Adds 'version' and 'authorinoVersion' fields to build.yaml
- Makefile reads VERSION, AUTHORINO_VERSION, and CHANNELS from build.yaml if present
- Uses simple grep/sed parsing to avoid yq dependency at variable definition time
- Removes make/release.mk (no longer needed)
- Falls back to defaults (git SHA, 'latest') if build.yaml doesn't exist

This allows release branches to automatically use the correct versions from
build.yaml for 'make verify-manifests' and 'make verify-bundle' in CI,
while dev branches without build.yaml continue to work with default values.

Signed-off-by: Guilherme Cassolato <guicassolato@gmail.com>
- Fix VERSION fallback logic in Makefile to properly fall back to git SHA when build.yaml is missing
- Add permissions blocks for least privilege access (contents: read)
- Pin actions/checkout to commit SHA (v4.2.2) and disable persist-credentials
- Fix fallback logic for missing fields in build.yaml using parameter expansion
- Read channels and defaultChannel from build.yaml instead of hardcoding to 'stable'
- Replace 'secrets: inherit' with explicit secret mapping (IMG_REGISTRY_USERNAME, IMG_REGISTRY_TOKEN)
- Add comment explaining why only registry secrets are passed

Signed-off-by: Guilherme Cassolato <guicassolato@gmail.com>
@guicassolato guicassolato force-pushed the use-build-yaml-for-release-config branch from be0c3ab to 7a17cac Compare June 22, 2026 12:00

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build-images-branches.yaml:
- Around line 69-71: The reusable workflow build-images-base.yaml is missing the
secret declarations for IMG_REGISTRY_USERNAME and IMG_REGISTRY_TOKEN that are
being passed from build-images-branches.yaml. Add a secrets section under
on.workflow_call in build-images-base.yaml that declares both
IMG_REGISTRY_USERNAME and IMG_REGISTRY_TOKEN, marking each as required: true, so
the workflow properly validates and accepts these secrets from the caller.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 32770a71-896a-4059-b2ae-7f8be3c8a5be

📥 Commits

Reviewing files that changed from the base of the PR and between b5fcb9e and 7a17cac.

📒 Files selected for processing (2)
  • .github/workflows/build-images-branches.yaml
  • Makefile
🚧 Files skipped from review as they are similar to previous changes (1)
  • Makefile

Comment on lines +69 to +71
secrets:
IMG_REGISTRY_USERNAME: ${{ secrets.IMG_REGISTRY_USERNAME }}
IMG_REGISTRY_TOKEN: ${{ secrets.IMG_REGISTRY_TOKEN }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Checking reusable workflow secret declarations..."
fd -a "build-images-base.yaml" .github/workflows --exec sed -n '1,220p' {}

echo
echo "Looking for workflow_call secret declarations..."
rg -n -C3 'workflow_call|secrets:|IMG_REGISTRY_USERNAME|IMG_REGISTRY_TOKEN' .github/workflows/build-images-base.yaml

Repository: Kuadrant/authorino-operator

Length of output: 9680


Reusable-workflow secret contract is broken.

The build-images-base.yaml workflow uses IMG_REGISTRY_USERNAME and IMG_REGISTRY_TOKEN secrets in its jobs, but does not declare them under on.workflow_call.secrets. When the caller passes these secrets (lines 69–71), the workflow will fail validation or at runtime.

Add the following to build-images-base.yaml under on.workflow_call:

Suggested fix
on:
  workflow_call:
    inputs:
      # ... existing inputs ...
    secrets:
      IMG_REGISTRY_USERNAME:
        required: true
      IMG_REGISTRY_TOKEN:
        required: true
🧰 Tools
🪛 actionlint (1.7.12)

[error] 70-70: secret "IMG_REGISTRY_USERNAME" is not defined in "./.github/workflows/build-images-base.yaml" reusable workflow. no secret is defined

(workflow-call)


[error] 71-71: secret "IMG_REGISTRY_TOKEN" is not defined in "./.github/workflows/build-images-base.yaml" reusable workflow. no secret is defined

(workflow-call)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build-images-branches.yaml around lines 69 - 71, The
reusable workflow build-images-base.yaml is missing the secret declarations for
IMG_REGISTRY_USERNAME and IMG_REGISTRY_TOKEN that are being passed from
build-images-branches.yaml. Add a secrets section under on.workflow_call in
build-images-base.yaml that declares both IMG_REGISTRY_USERNAME and
IMG_REGISTRY_TOKEN, marking each as required: true, so the workflow properly
validates and accepts these secrets from the caller.

Source: Linters/SAST tools

@Boomatang

Copy link
Copy Markdown
Member

I am going to say hold off on this for a little bit. I like the idea, and there is currently a RFC looking to standardize this across the different repo. It is planned to be talked about in the community call on June 23rd.

Here is a link to the RFC Kuadrant/limitador#494 , and here is a link to a draft PR I have in autorino, Kuadrant/authorino#634, it still needs a bit of testing, but the layout would be the same.

@eguzki

eguzki commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

This is partially covering #329.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

5 participants