CNF-23812: Add OLM annotation lint workflow

[sebrandon1]

Summary

• Add a GitHub Actions workflow that runs openshift-kni/olm-annotation-lint v1.0.2 on pull requests
• Validates all OLM annotations (olm.*, operatorframework.io/*) on Kubernetes resources in the repo
• Add make olm-annotation-lint target for running the linter locally — auto-detects OS/arch, downloads the latest release binary to a temp file, runs it, and cleans up automatically

This would have caught the invalid olm.operatorframework.io/bundle-install-timeout annotation that was removed in #759. Going forward, any PR introducing an unknown, mistyped, or misused OLM annotation will fail CI.

Related to

• CNF-24997: Add OLM annotation linting workflow cnf-features-deploy#4197

What it checks

• Unknown OLM annotations
• Valid annotations on wrong resource types
• Invalid duration values
• Wrong annotation prefixes
• Case mismatches
• Controller-managed annotations set by users

Local usage

make olm-annotation-lint

No dependencies required — the binary is downloaded from the latest GitHub release and removed after execution.

Test plan

• CI passes on this PR (the linter runs against the repo and finds no violations)
• Verify the workflow appears in the Actions tab
• Verify make olm-annotation-lint works locally

[openshift-ci-robot]

@sebrandon1: This pull request references CNF-23812 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Add a GitHub Actions workflow that runs openshift-kni/olm-annotation-lint on pull requests
• Validates all OLM annotations (olm.*, operatorframework.io/*) on Kubernetes resources in the repo

This would have caught the invalid olm.operatorframework.io/bundle-install-timeout annotation that was removed in #759. Going forward, any PR introducing an unknown, mistyped, or misused OLM annotation will fail CI.

What it checks

• Unknown OLM annotations
• Valid annotations on wrong resource types
• Invalid duration values
• Wrong annotation prefixes
• Case mismatches
• Controller-managed annotations set by users

Test plan

• CI passes on this PR (the linter runs against the repo and finds no violations)
• Verify the workflow appears in the Actions tab

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.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sebrandon1
Once this PR has been reviewed and has the lgtm label, please assign irinamihai for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a pull-request GitHub Actions workflow and a Makefile target to run the OLM annotation linter against the repository root while excluding testdata and vendor.

Changes

OLM Annotation Linting

Layer / File(s)	Summary
Annotation linting workflow configuration .github/workflows/olm-annotation-lint.yml	Adds a pull-request-triggered workflow with a single olm-lint job that checks out the repository and runs openshift-kni/olm-annotation-lint@v1 against . excluding testdata and vendor.
Makefile lint target Makefile	Adds a .PHONY olm-annotation-lint target which downloads the appropriate olm-annotation-lint binary for the host, runs it over the repo (--path .), and excludes testdata and vendor.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'CNF-23812: Add OLM annotation lint workflow' clearly and specifically describes the main change: adding an OLM annotation lint workflow, matching the changeset which adds both a GitHub Actions workflow and a Makefile target for this purpose.
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.
Description check	✅ Passed	The description clearly relates to the changeset, detailing the addition of a GitHub Actions workflow for OLM annotation linting and a corresponding Makefile target.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[imiller0]

I really like the checking of annotations and deeper verification that this brings, but three questions:

1. How does the lint checking maintain version awareness
2. How do we keep the lint checking from becoming stale (eg fails b/c a new annotation was added that the checker is not yet aware of)
3. How can we run the same verification in our local sandboxes? Or in agentic flows how can an agent make use of the validation locally?

[sebrandon1]

Good questions!

For:

1. The olm-annotation-lint repo has dependabot setup and updates the go.mod entry for new versions of OLM automatically with PRs. We can merge and release olm-annotation-lint with new versions as they arise.
2. I'm going to add a way for users to override/allow any annotation they want in the config for the action. That'll add flexibility.
3. I'll look into building and publishing an image of the olm-annotation-lint with a corresponding Make path for running it locally.

I'll ping you when it's updated.

[openshift-ci-robot]

@sebrandon1: This pull request references CNF-23812 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Add a GitHub Actions workflow that runs openshift-kni/olm-annotation-lint v1.0.2 on pull requests
• Validates all OLM annotations (olm.*, operatorframework.io/*) on Kubernetes resources in the repo
• Add make olm-annotation-lint target for running the linter locally — auto-detects OS/arch, downloads the latest release binary to a temp file, runs it, and cleans up automatically

This would have caught the invalid olm.operatorframework.io/bundle-install-timeout annotation that was removed in #759. Going forward, any PR introducing an unknown, mistyped, or misused OLM annotation will fail CI.

What it checks

• Unknown OLM annotations
• Valid annotations on wrong resource types
• Invalid duration values
• Wrong annotation prefixes
• Case mismatches
• Controller-managed annotations set by users

Local usage

make olm-annotation-lint

No dependencies required — the binary is downloaded from the latest GitHub release and removed after execution.

Test plan

• CI passes on this PR (the linter runs against the repo and finds no violations)
• Verify the workflow appears in the Actions tab
• Verify make olm-annotation-lint works locally

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.

[sebrandon1]

Okay I have created a make olm-annotation-lint path in the Makefile which will download a corresponding binary for your local system architecture (amd64 or arm64) and then run the same flags that the action does. I figured that would be the better way of doing it instead of creating an image and relying on users having Docker or Podman installed.

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/olm-annotation-lint.yml (1)

8-9: ⚡ Quick win

Consider pinning actions to commit SHAs for supply chain security.

Using version tags like @v6 and @v1 allows the underlying action code to change without notice if tags are moved. Pinning to immutable commit SHAs prevents unexpected changes and supply chain attacks.

🔒 Example: pinning to commit SHA

-      - uses: actions/checkout@v6
-      - uses: openshift-kni/olm-annotation-lint@v1
+      - uses: actions/checkout@ea960f4e5f8dc486d805e0d398e0b8d75443c3fc  # v6
+      - uses: openshift-kni/olm-annotation-lint@<commit-sha>  # v1

You can find the current commit SHA for each action version in their respective repositories.

🤖 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/olm-annotation-lint.yml around lines 8 - 9, The workflow
currently uses mutable tags for actions (uses: actions/checkout@v6 and uses:
openshift-kni/olm-annotation-lint@v1); replace those tag references with the
corresponding commit SHAs to pin each action to an immutable revision (e.g.,
uses: actions/checkout@<commit-sha> and uses:
openshift-kni/olm-annotation-lint@<commit-sha>), locating the exact SHAs from
each action's repository and updating the two uses lines in the workflow file.

🤖 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.

Nitpick comments:
In @.github/workflows/olm-annotation-lint.yml:
- Around line 8-9: The workflow currently uses mutable tags for actions (uses:
actions/checkout@v6 and uses: openshift-kni/olm-annotation-lint@v1); replace
those tag references with the corresponding commit SHAs to pin each action to an
immutable revision (e.g., uses: actions/checkout@<commit-sha> and uses:
openshift-kni/olm-annotation-lint@<commit-sha>), locating the exact SHAs from
each action's repository and updating the two uses lines in the workflow file.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 9ec84720-b243-43a0-ba11-f2dfb45f41f6

📥 Commits

Reviewing files that changed from the base of the PR and between 93a6300 and 58fdabf.

📒 Files selected for processing (2)

• .github/workflows/olm-annotation-lint.yml
• Makefile

[openshift-ci-robot]

@sebrandon1: This pull request references CNF-23812 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Add a GitHub Actions workflow that runs openshift-kni/olm-annotation-lint v1.0.2 on pull requests
• Validates all OLM annotations (olm.*, operatorframework.io/*) on Kubernetes resources in the repo
• Add make olm-annotation-lint target for running the linter locally — auto-detects OS/arch, downloads the latest release binary to a temp file, runs it, and cleans up automatically

This would have caught the invalid olm.operatorframework.io/bundle-install-timeout annotation that was removed in #759. Going forward, any PR introducing an unknown, mistyped, or misused OLM annotation will fail CI.

Related to

• CNF-24997: Add OLM annotation linting workflow cnf-features-deploy#4197

What it checks

• Unknown OLM annotations
• Valid annotations on wrong resource types
• Invalid duration values
• Wrong annotation prefixes
• Case mismatches
• Controller-managed annotations set by users

Local usage

make olm-annotation-lint

No dependencies required — the binary is downloaded from the latest GitHub release and removed after execution.

Test plan

• CI passes on this PR (the linter runs against the repo and finds no violations)
• Verify the workflow appears in the Actions tab
• Verify make olm-annotation-lint works locally

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.