NO-ISSUE: fix: set channel.default.v1 annotation to bundle's own channel by Marcusk19 · Pull Request #1260 · quay/quay-operator

Marcusk19 · 2026-05-14T14:39:06Z

Summary

Fix hack/prepare-upstream.sh to set the bundle's channel.default.v1 annotation to CHANNEL (the bundle's own channel) instead of DEFAULT_CHANNEL (the package-level default channel).
When releasing a z-stream for an older channel (e.g. stable-3.9), the bundle annotations were previously set to channel.default.v1: stable-3.17 and channels.v1: stable-3.9. This caused the community-operators-prod FBC pipeline to fail.
This aligns prepare-upstream.sh with hack/build.sh, which already uses CHANNEL for both annotations.

Problem

The build_scratch_catalog.py step in the operator-pipelines FBC validation creates a minimal scratch catalog containing only the bundle's declared channel (channels.v1). It then reads channel.default.v1 from the bundle annotations and sets that as the defaultChannel in the catalog. When channel.default.v1 points to a channel that doesn't exist in the scratch catalog (e.g. stable-3.17 when the bundle only belongs to stable-3.9), OPM rejects the catalog with a validation error.

The package-level default channel is managed in the FBC catalog template (catalogs/*/catalog-template.yaml), not in individual bundle annotations. Setting channel.default.v1 to the bundle's own channel is the correct behavior for bundle-level metadata.

Discovered while investigating community-operators-prod failures: #9576, #9572, #9570.

Test plan

Verify that running prepare-release with CHANNEL=stable-3.9 and DEFAULT_CHANNEL=stable-3.17 now produces channel.default.v1: stable-3.9 in bundle/metadata/annotations.yaml
Confirm that the generated bundle passes the FBC scratch catalog validation in operator-pipelines

🤖 Generated with Claude Code

The prepare-upstream.sh script was setting the bundle's channel.default.v1 annotation to DEFAULT_CHANNEL (the package-level default, e.g. stable-3.17), even when the bundle only belongs to a different channel (e.g. stable-3.9). This causes the community-operators FBC pipeline to fail: the build-fbc-scratch-catalog step creates a minimal scratch catalog containing only the bundle's channel but sets defaultChannel to the value from channel.default.v1 — OPM rejects this because the referenced default channel doesn't exist in the catalog. The fix changes channel.default.v1 to use CHANNEL (the bundle's own channel) instead of DEFAULT_CHANNEL. The package-level default channel is managed separately in the FBC catalog template, not in individual bundle annotations. This is consistent with hack/build.sh which already uses CHANNEL for both annotations. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Marcus Kok <mkok@redhat.com>

coderabbitai · 2026-05-14T14:39:20Z

Walkthrough

The operator bundle preparation script now uses the CHANNEL environment variable instead of DEFAULT_CHANNEL when setting the bundle's default channel annotation in metadata.

Changes

Bundle Channel Annotation Update

Layer / File(s)	Summary
Default channel annotation configuration `hack/prepare-upstream.sh`	The `yq` operation that annotates the operator bundle metadata now references the `CHANNEL` environment variable for the `operators.operatorframework.io.bundle.channel.default.v1` annotation field.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is clearly related to the changeset, providing detailed context about the problem, root cause, and rationale for the fix.
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.
Title check	✅ Passed	The title clearly summarizes the main change: setting the channel.default.v1 annotation to the bundle's own channel instead of DEFAULT_CHANNEL, which directly corresponds to the single line change in hack/prepare-upstream.sh.

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

✨ Finishing Touches

✨ Simplify code

Create PR with simplified code

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

Generate code and open pull requests
Plan features and break down work
Investigate incidents and troubleshoot customer tickets together
Automate recurring tasks and respond to alerts with triggers
Summarize progress and report instantly

Built for teams:

Shared memory across your entire org—no repeating context
Per-thread sandboxes to safely plan and execute work
Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

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

openshift-ci-robot · 2026-05-14T14:40:31Z

@Marcusk19: This pull request explicitly references no jira issue.

Details

In response to this:

Summary

Fix hack/prepare-upstream.sh to set the bundle's channel.default.v1 annotation to CHANNEL (the bundle's own channel) instead of DEFAULT_CHANNEL (the package-level default channel).

When releasing a z-stream for an older channel (e.g. stable-3.9), the bundle annotations were previously set to channel.default.v1: stable-3.17 and channels.v1: stable-3.9. This caused the community-operators-prod FBC pipeline to fail.

This aligns prepare-upstream.sh with hack/build.sh, which already uses CHANNEL for both annotations.

Problem

The build_scratch_catalog.py step in the operator-pipelines FBC validation creates a minimal scratch catalog containing only the bundle's declared channel (channels.v1). It then reads channel.default.v1 from the bundle annotations and sets that as the defaultChannel in the catalog. When channel.default.v1 points to a channel that doesn't exist in the scratch catalog (e.g. stable-3.17 when the bundle only belongs to stable-3.9), OPM rejects the catalog with a validation error.

The package-level default channel is managed in the FBC catalog template (catalogs/*/catalog-template.yaml), not in individual bundle annotations. Setting channel.default.v1 to the bundle's own channel is the correct behavior for bundle-level metadata.

Discovered while investigating community-operators-prod failures: #9576, #9572, #9570.

Test plan

Verify that running prepare-release with CHANNEL=stable-3.9 and DEFAULT_CHANNEL=stable-3.17 now produces channel.default.v1: stable-3.9 in bundle/metadata/annotations.yaml

Confirm that the generated bundle passes the FBC scratch catalog validation in operator-pipelines

🤖 Generated with Claude Code

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Marcusk19 · 2026-05-14T16:53:06Z

/cherrypick redhat-3.17

Marcusk19 · 2026-05-14T16:53:12Z

/cherrypick redhat-3.16

Marcusk19 · 2026-05-14T16:53:18Z

/cherrypick redhat-3.15

Marcusk19 · 2026-05-14T16:53:24Z

/cherrypick redhat-3.14

Marcusk19 · 2026-05-14T16:53:34Z

/cherrypick redhat-3.12

Marcusk19 · 2026-05-14T16:53:43Z

/cherrypick redhat-3.10

Marcusk19 · 2026-05-14T16:53:49Z

/cherrypick redhat-3.9

openshift-cherrypick-robot · 2026-05-14T16:53:52Z

@Marcusk19: new pull request created: #1261

Details

In response to this:

/cherrypick redhat-3.17