We can start by supporting the OCI repositories without CLI and GUI support. Users can apply an ArgoCD application via kubectl commands. We did a similar exercise for Multiple sources application. UI and CLI support can be included as a follow-up to the OCI support itself. To support OCI, we would need the below changes:{}

1. Credential Management (Repository Secret)
2. Investigate appropriate methods for managing authentication to OCI registries
3. Introduce new mechanisms or build upon existing functionality
4. Differentiation between OCI based Helm Charts?
5. repo-creds secret type can probably be reused

1. Repo Server Integration
2. Investigate feasibility of defining new interface for managing content sources (Git/Helm/OCI)
3. Develop capabilities to generate manifests from OCI source
4. Ensure path transversal is maintained/handled

1. Webhook Integration
2. Accept reception via invocation from OCI registries
3. Investigate payloads from major OCI registries (DockerHub, Quay, GitHub Container Registry, Google Container Registry, etc) to determine requirements
4. Define new key(s) in argocd-secret for OCI webhook support

Epic Goal

• ArgoCD to accept OCI repository sources

Why is this important?

• …

Scenarios

1. ...

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment