Story (Required)

As an administrator, I want to configure the imagePullPolicy for GitOps/Argo CD components at two levels:

1. Operator (Subscription) level – define a global default policy that applies to all Argo CD instances managed by the GitOps Operator.
2. ArgoCD CR level – allow overriding the global default per Argo CD instance or per component.

This story tracks the support of imagePullPolicy in Gitops Service CR.

Background and Approach (Required)

Today, GitOps components default to imagePullPolicy: Always. This leads to unnecessary image pulls during pod restarts and node maintenance, causing extra network usage and slower pod startup times. By enabling configuration:

• Administrators can reduce network load in production by using cached images (IfNotPresent).

• Developers can still use Always in test environments to ensure latest image updates.

• The operator provides flexibility and control, improving both performance and operational efficiency.

Approach

• Extend GitOps Operator Subscription to include an IMAGE_PULL_POLICY parameter  via environment variable. This value will be passed into the operator’s controller logic.

• Update the ArgoCD CRD schema to introduce a spec.imagePullPolicy field at both global.

• Enhance reconciliation logic:
  • On reconciling an ArgoCD CR, check if spec.imagePullPolicy is set.
  • If not set, use the Subscription-level default.
  • If neither is set, default to Always.
• Add unit and e2e tests to validate:
  • Subscription-only config.
  • CR-only config.
  • CR overriding Subscription.
  • Backward compatibility with existing clusters.

• Provide operator documentation with configuration examples.

Out of Scope

• <Defines what is not included in this story.>

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• <Describe edge cases to consider when implementing the story and defining tests.>
• <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story.>

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.