feat(EC-1797): support version constraints for git resolver task references

[robnester-rh]

Summary

• Extracts version from git resolver pathInRepo using the Tekton catalog convention (type/name/version/filename)
• Enables trusted_task_rules version constraints to work with git resolver tasks, not just OCI bundles
• Adds a unified _get_task_version function that chains OCI manifest annotation lookup with git path extraction
• Preserves fail-closed behavior when no version can be determined

Test plan

• 928/928 tests pass with 100% coverage
• Git task with version in path satisfies allow rule version constraints
• Git task with version in path correctly denied by deny rule version constraints
• Git task without version in path fails closed (not allowed / denied)
• Git task without version constraints in rule works regardless of path
• Existing bundle version constraint tests unaffected

🤖 Generated with Claude Code

[qodo-for-conforma]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 12 rules

1. Weak path convention validation ✓ Resolved 🐞 Bug ≡ Correctness

Description

_get_git_path_version is documented as parsing type/name/version/filename but only checks for 3
segments, so malformed paths (missing filename) can still be treated as versioned and participate in
version-constrained allow/deny decisions.

Code

policy/lib/tekton/trusted.rego[R589-596]

+# Extracts version from git resolver pathInRepo using Tekton catalog conventions.
+# Paths follow the pattern type/name/version/filename (e.g., task/buildah/0.3/buildah.yaml).
+_get_git_path_version(ref) := version if {
+	path := ref.pathInRepo
+	path != ""
+	parts := split(path, "/")
+	count(parts) >= 3
+	version := parts[2]

Relevance

⭐⭐⭐ High

Team typically accepts edge-case correctness tightening with tests around parsing/validation (see
version-constraint work in PR #1609).

PR-#1609

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The function explicitly documents a 4-segment convention but only enforces a 3-segment minimum,
which allows paths that don’t match the documented structure to still yield a "version".

policy/lib/tekton/trusted.rego[589-596]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`_get_git_path_version` claims to follow the Tekton catalog convention `type/name/version/filename`, but it currently only requires `count(parts) >= 3`. This can misclassify paths like `task/buildah/0.3` (no filename) as having a valid version.

### Issue Context
This impacts `trusted_task_rules` version constraints for git resolver tasks. A too-permissive parser increases the chance that non-conforming paths unintentionally satisfy or trigger version-constrained allow/deny rules.

### Fix Focus Areas
- policy/lib/tekton/trusted.rego[589-598]

### Suggested fix
Update the guard to require at least 4 segments (so a filename segment exists):
- Change `count(parts) >= 3` to `count(parts) >= 4`

Optionally, if you want stricter adherence to catalog layout without breaking legitimate use cases, consider also validating that `parts[0]` is one of expected catalog types (e.g., `task`, `stepaction`, etc.) and add unit tests for the boundary cases.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. _get_task_version lacks METADATA 📘 Rule violation ⚙ Maintainability

Description

New Rego rules _get_task_version and _get_git_path_version were added without a METADATA
annotation block containing the required fields (title, description, custom.short_name,
custom.failure_msg). This violates the policy annotation requirement and can break/undermine
policy documentation and governance expectations.

Code

policy/lib/tekton/trusted.rego[R573-582]

+# Returns the task version from either OCI manifest annotations or git path conventions.
+_get_task_version(ref, bundle_manifests) := version if {
+	version := _get_manifest_version_annotation(ref, bundle_manifests)
+} else := version if {
+	version := _get_git_path_version(ref)
+}
+
# Returns the version annotation from the manifest for a bundle reference.
# bundle_manifests is a map of bundle_ref -> manifest from ec.oci.image_manifests
_get_manifest_version_annotation(ref, bundle_manifests) := version if {

Relevance

⭐⭐⭐ High

Team has fixed missing METADATA before to unblock docs/governance (PR #1412); metadata blocks are
expected.

PR-#1412
PR-#1708

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 98 requires a METADATA block with specific non-empty fields for added/modified
policy rules. The added rules at the cited location include only standard comments and no METADATA
block or required fields.

Rule 98: Require METADATA annotation block in all policy rules
policy/lib/tekton/trusted.rego[573-598]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Newly added rules in `policy/lib/tekton/trusted.rego` are missing the required `METADATA` annotation block (with non-empty `title`, `description`, `custom.short_name`, and `custom.failure_msg`).

## Issue Context
This PR adds `_get_task_version` and `_get_git_path_version` rules, but only includes descriptive comments. The compliance checklist requires explicit `METADATA` blocks for added/modified policy rules.

## Fix Focus Areas
- policy/lib/tekton/trusted.rego[573-598]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Truncated git versions ✓ Resolved 🐞 Bug ≡ Correctness

Description

_get_git_path_version accepts versions with more than three numeric components (e.g. 1.2.3.4), but
_normalize_version only keeps major.minor.patch, so constraints can be evaluated against a silently
altered version and allow/deny results can be wrong.

Code

policy/lib/tekton/trusted.rego[R594-597]

+	parts := split(path, "/")
+	count(parts) >= 3
+	version := parts[2]
+	regex.match(`^v?\d+(\.\d+)*$`, version)

Relevance

⭐⭐ Medium

No clear precedent on rejecting/allowing 4-part versions vs truncating to major.minor.patch; could
be intended behavior.

PR-#1609

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The git path extractor accepts unlimited numeric dot components, while normalization only uses the
first three components, which means versions like 1.2.3.4 would be compared as 1.2.3.

policy/lib/tekton/trusted.rego[589-598]
policy/lib/tekton/trusted.rego[532-548]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`_get_git_path_version` currently accepts version strings with unlimited dot-separated numeric components (e.g. `1.2.3.4`). Downstream, `_normalize_version` truncates to the first three components (`major.minor.patch`), so policy decisions can be made against the wrong version.

### Issue Context
This affects `trusted_task_rules` version constraints for git resolver task references. A path segment like `.../1.2.3.4/...` can be treated as `1.2.3`, potentially allowing versions that should be rejected by constraints like `<=1.2.3`.

### Fix Focus Areas
- policy/lib/tekton/trusted.rego[589-598]
- policy/lib/tekton/trusted.rego[532-548]

### Suggested fix
Tighten accepted git versions to match the normalization/semver expectations, e.g.:
- Change the regex to allow only 1–3 numeric components: `^v?\d+(\.\d+){0,2}$`, and/or
- Add a guard in `_normalize_version` to fail (return undefined) when `count(parts) > 3` so extra components are not silently ignored.

Also add a unit test demonstrating that `task/x/1.2.3.4/y.yaml` does **not** produce a usable version (or is treated as invalid for version constraints).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 0a26b853-8763-4e96-9338-b6a0b74edb1b

📥 Commits

Reviewing files that changed from the base of the PR and between 1bc7aaf and c17a25e.

📒 Files selected for processing (2)

• policy/lib/tekton/trusted.rego
• policy/lib/tekton/trusted_test.rego

🚧 Files skipped from review as they are similar to previous changes (1)

• policy/lib/tekton/trusted.rego

---

📝 Walkthrough

Walkthrough

This PR extends trusted task version evaluation to extract task versions from git repository paths when manifest annotations are unavailable. New helpers parse Tekton catalog-style paths and integrate fallback version selection into existing semver constraint evaluation, with comprehensive test coverage for allow/deny/fail-closed scenarios.

Changes

Git path version extraction and constraint integration

Layer / File(s)	Summary
Version extraction helpers policy/lib/tekton/trusted.rego, policy/lib/tekton/trusted_test.rego	Added _get_task_version to select between manifest annotation and git path versions. Implemented _get_git_path_version to parse Tekton catalog-style paths and extract dotted version strings, validating resource types and accepting only versions matching optional-v numeric dotted format. Unit test validates extraction across multiple pathInRepo patterns, including valid versions, v-prefixed versions, and rejection of invalid/missing/malformed paths.
Constraint evaluation with version fallback integration policy/lib/tekton/trusted.rego, policy/lib/tekton/trusted_test.rego	Modified _version_satisfies_all_rule_constraints and _version_satisfies_any_rule_constraints to use the new fallback version selection. Tests verify allow-range matching (matching versions trusted, non-matching rejected), deny-range precedence (deny constraints override allow), fail-closed behavior (missing version components with constraints = deny), and unconditional allow when rules omit version constraints. Added _mock_git_task helper for consistent test construction.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main feature: enabling version constraints for git resolver task references, which aligns with the primary changes in the changeset.
Description check	✅ Passed	The description is directly related to the changeset, detailing the version extraction from git paths, enabling version constraints, and test coverage for git resolver tasks.
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

---

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
unit-tests	100.00% <100.00%> (ø)

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

Files with missing lines	Coverage Δ
policy/lib/tekton/trusted.rego	100.00% <100.00%> (ø)
policy/lib/tekton/trusted_test.rego	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coderabbitai]

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 `@policy/lib/tekton/trusted.rego`:
- Around line 591-598: The helper _get_git_path_version currently only checks
the third segment for a version; update it to validate the full catalog path
shape (type/name/version/filename) before returning a version: ensure
ref.pathInRepo is non-empty, split(path, "/") yields at least 4 parts, parts[0]
(type) and parts[1] (name) are non-empty, and parts[2] matches the version
regex; only then set and return version from parts[2] in _get_git_path_version.

🪄 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: Enterprise

Run ID: 3000ff49-69b0-4a40-b3bd-1740542bf22c

📥 Commits

Reviewing files that changed from the base of the PR and between 8ab3082 and 1bc7aaf.

📒 Files selected for processing (2)

• policy/lib/tekton/trusted.rego
• policy/lib/tekton/trusted_test.rego

[fullsend-ai-review]

Review

Findings

Low

• [edge-case] policy/lib/tekton/trusted.rego:636 — _get_git_path_version uses count(parts) >= 4 to validate path structure but does not verify that the filename segment (parts[3]) is non-empty. A path with a trailing slash like task/buildah/0.3/ produces ["task", "buildah", "0.3", ""] which passes the count check and extracts version 0.3. Not a security issue (version is still regex-validated and errs on the side of matching), but a minor laxity in input validation.

Info

• [test-coverage] policy/lib/tekton/trusted_test.rego — No test covers the precedence behavior of _get_task_version when both OCI manifest annotation and git path could provide a version. A test confirming OCI manifest takes priority would strengthen confidence in the chaining logic.

• [documentation] policy/lib/tekton/trusted.rego:628 — _get_git_path_version(ref) parameter ref is a task reference structure with git resolver fields, not a raw path string. The existing comments are adequate but an inline note on the expected ref shape would improve discoverability.

Previous run

Review

Findings

Low

• [test-coverage-gap] policy/lib/tekton/trusted_test.rego — The existing unit tests for _version_satisfies_all_rule_constraints and _version_satisfies_any_rule_constraints only test with bundle-style refs (objects containing a bundle key). After this PR, these functions internally call _get_task_version which chains OCI and git lookups. The integration tests (test_git_task_version_constraints_allow, test_git_task_version_constraints_deny, etc.) cover the end-to-end path through is_trusted_task, but adding direct unit tests for the version constraint functions with git-style refs (e.g., {"pathInRepo": "task/buildah/0.3/buildah.yaml"}) would improve confidence in the fallback chaining.

Info

• [test-integrity] No existing tests were weakened or modified. All test changes are purely additive.
• [fail-closed-verified] Fail-closed behavior is preserved for both allow rules (task not allowed when no version found) and deny rules (task denied by default when no version found). The OCI-first fallback order in _get_task_version is safe — task_ref produces mutually exclusive ref objects for bundle vs git resolvers, preventing version source ambiguity.
• [path-validation-verified] The _get_git_path_version function correctly guards against non-catalog paths via the _catalog_types allowlist and validates version strings with an anchored regex. Path traversal attempts (e.g., ../) fail the regex check.

Previous run (2)

Review

Findings

Medium

• [trust-model] policy/lib/tekton/trusted.rego:510 — The deny-side logic in _version_satisfies_any_rule_constraints previously treated a missing version as "deny by default" (fail-closed). With the new _get_task_version fallback chain, a git resolver task whose pathInRepo follows catalog conventions (e.g., task/foo/2.0/foo.yaml) now extracts a version from the path. If that path-derived version does not match the deny rule's semver constraints, the deny rule no longer fires. This is the PR's intended behavior change, but it shifts version trust from server-side OCI manifest annotations (set at publish time by the task author) to pathInRepo (a parameter in the PipelineRun definition, controlled by the pipeline author). The risk is mitigated if attestation signature verification is a prerequisite for policy evaluation (ensuring pathInRepo integrity), but this trust model change deserves explicit human review.

Low

• [edge-case] policy/lib/tekton/trusted.rego:597 — The regex ^v?\d+(\.\d+){0,2}$ in _get_git_path_version accepts versions with leading zeros (e.g., 01.2.3). These are rejected downstream by semver.is_valid (fail-closed), so this is safe, but tightening the regex to reject leading zeros at extraction time would improve clarity.

• [stale-comment] policy/lib/tekton/trusted.rego:474 — The function-level docstring comments for _version_satisfies_all_rule_constraints (line 474) and _version_satisfies_any_rule_constraints (line 502) still reference "manifest version" but the implementation now uses _get_task_version which resolves versions from either OCI manifest annotations or git path conventions. The inline comment at line 509 was correctly updated but the docstrings were not.

Info

• [test-adequacy] policy/lib/tekton/trusted_test.rego:1045 — The tests for _get_git_path_version are comprehensive, but there is no direct test of _get_task_version verifying that OCI manifest annotations take precedence over git path extraction when both are available. While this scenario is unlikely (OCI bundle refs and git refs are mutually exclusive resolver types), a test documenting the intended precedence would be valuable.

• [version-source-integrity] policy/lib/tekton/trusted.rego:573 — The _get_task_version fallback chain introduces two version sources with different trust properties: OCI manifest annotations (set by the task publisher) vs. git path (specified by the pipeline consumer). If signed attestation verification is a prerequisite for policy evaluation, the risk is mitigated. Consider adding a code comment clarifying this trust assumption.

Previous run (3)

Review

Findings

Low

• [trust-model] policy/lib/tekton/trusted.rego:573 — The new _get_task_version fallback chain introduces a version source (git pathInRepo convention) with different provenance than OCI manifest annotations. OCI manifest versions are registry-attested metadata, while git path versions are a directory naming convention. In the Tekton catalog model, the path convention is authoritative and the revision is SHA-pinned, so this is a reasonable trust boundary. However, deny rules that previously blanket-denied git tasks (due to no manifest version) will now evaluate version constraints if a path version is extractable — this is the intended feature behavior but represents a change in deny-rule semantics worth noting for operators.

• [edge-case] policy/lib/tekton/trusted.rego:592 — _get_git_path_version assumes the Tekton catalog path convention (type/name/version/filename) and always extracts parts[2] as the version. Non-standard catalog layouts (e.g., additional directory nesting) will silently fail to extract a version. This is safe via fail-closed behavior (tasks without extractable versions are denied by allow rules and denied by deny rules), but could surprise users whose version constraints silently stop working with no diagnostic signal.

• [test-coverage] policy/lib/tekton/trusted_test.rego — Consider adding an explicit unit test for _get_task_version with a bundle ref that has a manifest version annotation, verifying the OCI manifest path is preferred over git path extraction. The existing _version_satisfies_*_rule_constraints tests with bundle refs cover this implicitly, but a direct test would document the intended priority.

• [comment-consistency] policy/lib/tekton/trusted.rego:573 — Every other function in this file that accepts a bundle_manifests parameter includes the comment # bundle_manifests is a map of bundle_ref -> manifest from ec.oci.image_manifests (13 occurrences). The new _get_task_version function omits this line, breaking the established documentation pattern.

Info

• [authorization] PR references external tracker ticket EC-1797 but has no linked GitHub issue. Authorization inferred from the conventional commit reference and the well-scoped nature of the change.

• [test-helper-naming] policy/lib/tekton/trusted_test.rego — Existing test helpers that construct mock data use a _mock_ prefix (e.g., _mock_bundle_manifests, _mock_image_manifests). The new helper _git_task_with_path does not follow this convention; _mock_git_task_with_path would be more consistent.

• [test-naming] policy/lib/tekton/trusted_test.rego — Existing tests for internal helpers mirror the function name (e.g., test_normalize_version for _normalize_version). The new test_git_version_extraction tests _get_git_path_version but uses a descriptive name rather than mirroring the function. Consider test_get_git_path_version for consistency.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:48 PM UTC · Completed 5:58 PM UTC
Commit: 47d3320 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:15 PM UTC · Completed 6:25 PM UTC
Commit: 47d3320 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:27 PM UTC · Completed 1:38 PM UTC
Commit: 47d3320 · View workflow run →

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 2:49 AM UTC · Completed 2:54 AM UTC
Commit: 47d3320 · View workflow run →

[fullsend-ai-retro]

Retro: PR #1741 — feat(EC-1797): support version constraints for git resolver task references

Verdict: Workflow went well overall. No new proposals — all identified improvement areas are already tracked by existing issues.

Timeline

1. June 8: Human-authored PR opened (co-authored with Claude Code). Three review bots ran: qodo, coderabbit, and fullsend-ai-review.
2. June 8: qodo and coderabbit flagged real correctness bugs (weak path validation requiring only 3 segments instead of 4, truncated version acceptance). Fullsend approved with low-severity edge-case findings covering similar ground.
3. June 8: Author pushed fix commit addressing qodo/coderabbit feedback (tightened path validation to ≥4 segments, tightened version regex).
4. June 8: Fullsend re-reviewed and approved again.
5. June 15: Author rebased after dependency PR fix: use glob.match for pattern matching in trusted_task_rules #1743 merged. Fullsend reviewed again with minor new findings.
6. June 23: Human reviewer joejstuart asked a design question about whether OCI and git version lookups should be chained together — a concern no bot raised.
7. June 24: PR merged after human approval.

Quality Assessment

Review quality (good, with known gaps):

• Fullsend correctly identified the trust-model semantic change, edge cases, and a test coverage gap about OCI vs git precedence. The test-coverage finding was actually predictive of the human reviewer's later design question.
• However, fullsend rated path validation issues as low-severity edge cases while other bots correctly flagged them as correctness bugs that needed fixing. If the author had relied solely on fullsend, they might not have addressed these.
• The human reviewer's design question ("is it wasteful to check OCI bundle version first for git-resolved tasks?") was the highest-signal feedback on the PR, and no bot surfaced it.

Rework rate: Low — 1 fix commit addressing reviewer feedback, plus 1 rebase. Reasonable for a 163-line feature.

Token cost: Fullsend ran 3-4 review passes, all approving. Some redundancy but within normal bounds.

Existing Issues That Cover Identified Gaps

• Severity calibration: #1144 — "Severity calibration: silent-failure correctness bugs should not be rated [low]" — directly applies to this PR where path validation bugs were rated low.
• Design-level review: #1469 — "Review agent should assess feature-level design, not just implementation" and #1194 — "Review agent should question necessity, not just correctness" — both apply to the missed chaining design question.
• Third-party bot integration: #664 — "Review agent: incorporate existing human and third-party bot reviews into assessment" — fullsend could have elevated its severity after seeing qodo/coderabbit flag the same issues as bugs.
• Rego paradigm guidance: conforma/policy#1757 — "Add Rego/OPA paradigm guidance to AGENTS.md" — some review findings (like the _mock_ prefix naming suggestion) reflect incomplete understanding of the codebase's Rego conventions.