proposal: stage-managed applications

[krancour]

From @wanghong230:

Thought: Consider putting Kargo more fused with Argo CD. Currently, it is two tier system, people need to worry about Argo CD and Kargo. With Kargo, it should be easier, rather than more complicated...

Defining/creating an Argo CD application within the Kargo stage definition could be a idea

I've had this thought before as well. It was even discussed early on, but we decided to start with the assumption that users are probably coming to the table already having a bunch of existing Applications that they'd like integrate with.

I agree it's now time to revisit this idea.

Note that there are significant technical challenges to this, so we shouldn't rush this.

[jkleinlercher]

We achieve this with a Helm Chart which creates

• a kargo project
• Warehouse
• Stages
• And ArgoCD application per stage

https://github.com/suxess-it/sx-cnp-oss/tree/feat/onboarding-apps/team-apps/onboarding-apps-charts/multi-stage-app-with-kargo-pipeline

Maybe this is a good starting point for the community. It still misses some things like adding AnalysesTemplates but it is a good start for us

[krancour]

I agree that charts can be a good way to approach this in the near-term.

And ArgoCD application per stage

Just note that this may work in only a minority of cases, since Argo CD Applications quite often need to exist in different clusters than the one where all the Kargo data lives.

[Brightside56]

Case I have in mind is to provide QA engineers a possibility to clickops environments. There is a wizard in 0.9.0, there is a possibility to assemble freight, but there is no possibility to manage ArgoCD applications OOTB... Even PoC of such feature could be very useful. Probably there could be a possibility to refer application template (stored in some CRD or configmap) from stage resource and probably even patch something there like Crossplane patch and transform does

spec:
  promotionMechanisms:
    gitRepoUpdates:
      - repoURL: ...
      ...
    argoCDAppUpdates:
      - appName: ...
  managedArgoCDApps:
    - templateRef:
        configMap:
          name: ...
          key: ...
      patch:
        - to: spec.source.path
          combine:
            fmt: > 
              %s/%s/%s
            variables:
              - fromFieldPath: project.metadata.name
              - fromFieldPath: stage.metadata.name
              - literal: xxxyyy

Then kargo-controller could render application from reference, patch it with known fields like name, repoURL and patches and manage it. In case when integration with existing application needed it can be done by name instead of reference

Integration with existing applications is useful for my cases. But issue is I'm using applicationset. I'm using applicationset because it provides a possibility to template cluster metadata (which may contain useful info such as AWS account id or infrastructure unit name) into application fields

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.