CMP-4599: Fix workloadNeedsUpdate to detect celContentFile changes

[taimurhafeez]

workloadNeedsUpdate only compared container images when deciding whether to re-deploy the profileparser workload. This meant that adding or changing spec.celContentFile on an already-VALID ProfileBundle was silently ignored — the controller logged "Skip reconcile: Workload already up-to-date" because the content image hadn't changed, even though the init container commands needed to include the new --cel-path flag and the additional cp command for the CEL content file.

Without a re-deploy, the old parser pod kept running with the old commands (no --cel-path), so CEL profiles like cis-vm-extension were never created. The ProfileBundle status stayed VALID from the initial XCCDF-only parse, and any downstream consumer waiting for CEL profiles would fail with "profile not found".

Compare the content-container shell command and profileparser command arguments against what contentCopyCommand and profileparserCommand would produce for the current ProfileBundle spec. When celContentFile is added or changed, the commands differ, workloadNeedsUpdate returns true, and the existing re-deploy logic sets status to PENDING, updates the deployment, and the parser re-runs with the CEL content included.

Co-authored by Claude.
Related PR.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: taimurhafeez

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [taimurhafeez]

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

[github-actions]

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:1345-ed8e6dee9bd1002aa6b77081aa7a3bb86790c656

[abushkin-redhat]

/lgtm

[openshift-ci-robot]

@taimurhafeez: This pull request references CMP-4599 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 sub-task to target the "5.1.0" version, but no target version was set.

Details

In response to this:

workloadNeedsUpdate only compared container images when deciding whether to re-deploy the profileparser workload. This meant that adding or changing spec.celContentFile on an already-VALID ProfileBundle was silently ignored — the controller logged "Skip reconcile: Workload already up-to-date" because the content image hadn't changed, even though the init container commands needed to include the new --cel-path flag and the additional cp command for the CEL content file.

Without a re-deploy, the old parser pod kept running with the old commands (no --cel-path), so CEL profiles like cis-vm-extension were never created. The ProfileBundle status stayed VALID from the initial XCCDF-only parse, and any downstream consumer waiting for CEL profiles would fail with "profile not found".

Compare the content-container shell command and profileparser command arguments against what contentCopyCommand and profileparserCommand would produce for the current ProfileBundle spec. When celContentFile is added or changed, the commands differ, workloadNeedsUpdate returns true, and the existing re-deploy logic sets status to PENDING, updates the deployment, and the parser re-runs with the CEL content included.

Related PR.

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.

[Vincent056]

/lgtm
/approve

[Vincent056]

/retest