feat(ISV-7024): Add when conditions to pipeline tasks

[Allda]

I reviewed the pipeline tasks to figure out if optional tasks can be
skipped using native "when" conditions. In some cases this is
applicable, however there are still limitation where it can't be used.
To document a guidelines I am adding a doc with examples and decision
tree of where the "when" can or can't be used.

The other part of the PR is focused on paralelization:
A subset of tasks in the hosted pipeline can run in parallel to speedup
the pipelinerun execution time. I identified several tasks and updated
pipeline dependency graph. There are more tasks that could be also
parallelized but it makes the graph readability more difficult. This
solution is compromise between speed and maintainability.

Merge Request Checklists

• Development is done in feature branches
• Code changes are submitted as pull request into a primary branch [Provide reason for non-primary branch submissions]
• Code changes are covered with unit and integration tests.
• Code passes all automated code tests:
  • Linting
  • Code formatter - Black
  • Security scanners
  • Unit tests
  • Integration tests
• Code is reviewed by at least 1 team member
• Pull request is tagged with "risk/good-to-go" label for minor changes

[qodo-code-review]

Review Summary by Qodo

Parallelize pipeline tasks and add when condition guidelines

✨ Enhancement

Walkthroughs

Description

• Parallelize pipeline tasks by updating dependency graph
  - Multiple tasks now depend on detect-changes instead of sequential chains
  - Reduces overall pipeline execution time while maintaining readability
• Add when conditions to conditionally skip tasks
  - Introduces reusable condition anchors for bundle path and cert project checks
  - Adds conditions to merge-registry-credentials, digest-pinning, and other tasks
• Reorganize task execution order for better parallelization
  - Move static-tests earlier in pipeline (after apply-test-waivers)
  - Remove resolve-pr-type and verify-pinned-digest tasks
  - Consolidate dependencies into get-pyxis-certification-data task
• Add documentation guidelines for Tekton when conditions
  - Document rules for safe usage of when conditions in pipelines
  - Provide decision tree and examples for when conditions can/cannot be used
• Enhance digest-pinning task with enforcement flag
  - Add enforce_pinning parameter to fail task on pinning violations

Diagram

flowchart LR
  DC["detect-changes"]
  DC --> YL["yaml-lint"]
  DC --> CP["check-permissions"]
  DC --> SGPT["set-github-pr-title"]
  DC --> RC["read-config"]
  DC --> ATW["apply-test-waivers"]
  DC --> CH["content-hash"]
  DC --> CPC["certification-project-check"]
  DC --> GO["get-organization"]
  ATW --> ST["static-tests"]
  CPC --> GPCD["get-pyxis-certification-data"]
  RC --> GPCD
  YL --> GPCD
  CP --> GPCD
  SGPT --> GPCD
  ST --> GPCD
  CH --> GPCD
  GPCD --> VCF["validate-catalog-format"]
  GPCD --> VP["verify-project"]
  GO --> VP
  VP --> MRC["merge-registry-credentials"]
  MRC --> DP["digest-pinning"]
  DP --> DFC["dockerfile-creation"]
  DFC --> BB["build-bundle"]

Loading

File Changes

1. ansible/roles/operator-pipeline/templates/openshift/pipelines/operator-hosted-pipeline.yml ✨ Enhancement +76/-82

Parallelize pipeline and add conditional task execution

• Restructured task dependencies to enable parallelization by having multiple tasks depend directly
 on detect-changes
• Moved static-tests task earlier in pipeline (after apply-test-waivers instead of after
 reserve-operator-name)
• Removed resolve-pr-type and verify-pinned-digest tasks from pipeline
• Consolidated multiple task dependencies into get-pyxis-certification-data task
• Added when conditions using reusable anchors (isBundlePathAvailable, isCertProjectRequired,
 certProjectExists) to conditionally skip tasks
• Updated task ordering for build-fbc-index-images, add-bundle-to-index, and
 build-fbc-scratch-catalog to depend on get-supported-versions
• Added when condition to link-pull-request-with-open-status and
 link-pull-request-with-merged-status tasks

ansible/roles/operator-pipeline/templates/openshift/pipelines/operator-hosted-pipeline.yml

---

2. ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml ✨ Enhancement +18/-4

Add enforce_pinning parameter and validation logic

• Added enforce_pinning parameter (default: "true") to control whether digest pinning violations
 cause task failure
• Enhanced script logic to fail task when enforce_pinning is true and manifests are not pinned
• Refactored related images validation logic to use a PASS flag variable
• Added enforcement check for related images validation to fail task when flag is false and
 enforcement is enabled

ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml

---

3. docs/tekton-when-condition-guidelines.md 📝 Documentation +182/-0

Add Tekton when condition usage guidelines documentation

• New documentation file defining guidelines for safe usage of Tekton when conditions in pipelines
• Provides rules-at-a-glance table with five scenarios and their allowed status
• Includes detailed explanations for four main rules with code examples
• Provides decision tree flowchart for determining when conditions can be safely used
• Explains risks of skipped tasks and empty result propagation in pipeline graphs

docs/tekton-when-condition-guidelines.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. CI pinning auto-commit blocked ☑ 🐞 Bug ≡ Correctness

Description

digest-pinning now exits non-zero when it detects unpinned manifests or relatedImages mismatches
and enforce_pinning is left at its default of "true", which prevents operator-ci-pipeline from
reaching commit-pinned-digest to push the pinned branch. This turns a previously auto-fix workflow
(pin then commit) into a hard failure whenever pinning is needed.

Code

ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[R107-113]

        if [[ $REPLACEMENT_COUNT -gt 0 ]]; then
          echo "Manifests were not pinned."
          echo -n "true" | tee $(results.dirty_flag.path)
+          if  [[ "$(params.enforce_pinning)" == "true" ]]; then
+            echo "Digest pinning is enforced. Failing the task."
+            exit 1
+          fi

Evidence

digest-pinning now conditionally exit 1 when it finds replacements or relatedImages problems and
enforce_pinning is "true"; since enforce_pinning is newly introduced with default "true" and
operator-ci-pipeline does not override it, CI will fail at digest-pinning exactly in the
scenario where CI is supposed to continue to commit-pinned-digest and push the pinned changes
branch (when dirty_flag is true).

ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[12-18]
ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[104-116]
ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[145-161]
ansible/roles/operator-pipeline/templates/openshift/pipelines/operator-ci-pipeline.yml[134-168]
ansible/roles/operator-pipeline/templates/openshift/tasks/commit-pinned-digest.yml[90-106]

Agent prompt

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

### Issue description
`digest-pinning` now fails the TaskRun (exit 1) when it detects unpinned images or relatedImages issues and `enforce_pinning` is `"true"`. Because `enforce_pinning` defaults to `"true"` and `operator-ci-pipeline` does not set it, CI will fail in the exact case where it should proceed to `commit-pinned-digest` to auto-commit the pinned changes.

### Issue Context
- `operator-ci-pipeline` uses `digest-pinning` specifically to detect/perform pinning and then uses `dirty_flag` in `commit-pinned-digest` to push a `*-pinned` branch.
- The hosted pipeline may still want strict enforcement.

### Fix Focus Areas
- ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[12-18]
- ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[104-116]
- ansible/roles/operator-pipeline/templates/openshift/tasks/digest-pinning.yml[145-161]
- ansible/roles/operator-pipeline/templates/openshift/pipelines/operator-ci-pipeline.yml[134-152]
- ansible/roles/operator-pipeline/templates/openshift/pipelines/operator-hosted-pipeline.yml[709-724]

### Suggested change
1. Change `enforce_pinning` default to `"false"` in the Task definition.
2. In `operator-hosted-pipeline.yml`, explicitly pass `enforce_pinning: "true"` to keep current strict behavior.
3. In `operator-ci-pipeline.yml`, either omit `enforce_pinning` (to use the new default `false`) or explicitly set it to `"false"` for clarity.

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

---

ⓘ The new review experience is currently in Beta. Learn more

[mantomas]

Makes sense to me, one small nitpick.

[ezopezo]

I am missing the context of the removal of this - was this completely unused?

[Allda]

Yes it was not used in the hosted pipeline. We probably replaced it some time ago and didn't remove it.

[ezopezo]

Does it make a sense to skip static tests with when: *bundleAdded?

[Allda]

No, the static test also tests catalogs, and they are required in all workflows.

[ezopezo]

Well this might be safe if source task always run right? Or am I missing something?

[Allda]

That's the tricky part that made me spend a lot of time trying to debug it. If a task consumes any results, it doesn't matter if the task results in the when section is available or not. I updated text in this section to better explain it. The overall decision tree in this document should help with deciding when it is safe or not safe to use when.

[ezopezo]

Thanks for explanation!