Failure understand how to upgrade from kargo 1.0.x to 1.1.x - implicit configuration into explicit

[danielloader]

Anyone come across this?

This was working in kargo 1.0.3 but since upgrading to 1.1.1 it's now failing - given it's meant to be a bool, and says it can be false or null and I've got it set to true, kinda confused where to go next

apps.0.sources.0.updateTargetRevision must be one of the following: false, null

Guessing it's because I don't have an apps.0.sources.0.desiredRevision value, trying to work out which template I need to inject to get the prior behaviour now.

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: uat
  namespace: app-frontend
spec:
  promotionTemplate:
    spec:
      steps:
       - uses: argocd-update
         config:
          apps:
          - name: frontend-uat
            namespace: argocd
            sources:
            - repoURL: https://github.com/example/platform-applications
              updateTargetRevision: true
              desiredRevision: <WHAT GOES HERE NOW?>
              kustomize:
                images:
                  - repoURL: ghcr.io/example/frontend
                    newName: 12345678910.dkr.ecr.eu-west-2.amazonaws.com/ghcr.io/example/frontend
                    useDigest: false
  requestedFreight:
    - origin:
        kind: Warehouse
        name: frontend
      sources:
        direct: true

[krancour]

Can I see your Warehouse to get an idea of what artifacts are included in each piece of Freight?

[danielloader]

apiVersion: kargo.akuity.io/v1alpha1
kind: Warehouse
metadata:
  name: frontend
  namespace: app-frontend
spec:
  freightCreationPolicy: Automatic
  interval: 3m0s
  subscriptions:
    - image:
        allowTags: ^v?[0-9]+\.[0-9]+\.[0-9]+([\+-].*)?$
        discoveryLimit: 20
        imageSelectionStrategy: SemVer
        repoURL: ghcr.io/example/frontend
    - git:
        branch: main
        commitSelectionStrategy: NewestFromBranch
        discoveryLimit: 20
        includePaths:
          - manifests/frontend
          - bootstrap/applications/kargo-apps/frontend
        repoURL: https://github.com/example/platform-applications

[krancour]

Thanks. So, if your intention is to update the target revision to whatever commit from https://github.com/example/platform-applications was contained within the Freight, then your desiredRevision would be ${{ commitFrom('https://github.com/example/platform-applications').ID }}

[danielloader]

Perfect, worked!

Thanks for the help.

[danielloader]

@krancour only had partial success.

Now I have an warehouse with 2 sources:

apiVersion: kargo.akuity.io/v1alpha1
kind: Warehouse
metadata:
  name: openfga
  namespace: service-openfga
spec:
  freightCreationPolicy: Automatic
  interval: 1m0s
  subscriptions:
    - chart:
        name: openfga
        repoURL: https://openfga.github.io/helm-charts
        discoveryLimit: 5
    - git:
        branch: main
        commitSelectionStrategy: NewestFromBranch
        discoveryLimit: 5
        includePaths:
          - values/services/openfga
          - charts/defaults/openfga
        repoURL: https://github.com/example/platform-services

Stage in question:

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: uat
  namespace: service-openfga
spec:
  promotionTemplate:
    spec:
      steps:
       - uses: argocd-update
         retry:
          errorThreshold: 1
          timeout: 60s
         config:
          apps:
          - name: openfga-uat
            namespace: argocd
            sources:
            - repoURL: https://openfga.github.io/helm-charts
              updateTargetRevision: true
              desiredRevision: ${{ chartFrom('https://openfga.github.io/helm-charts', 'openfga').Version }}
              chart: openfga
            - repoURL: https://github.com/example/platform-services
              updateTargetRevision: true
              desiredRevision: ${{ commitFrom('https://github.com/example/platform-services').ID }}
  requestedFreight:
    - origin:
        kind: Warehouse
        name: openfga
      sources:
        direct: true

The argocd application has 3 sources as shown via its manifest (as sourced from argocd web UI):

project: addons
destination:
  namespace: openfga
  name: uat
syncPolicy:
  automated: {}
  syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true
sources:
  - repoURL: https://github.com/example/platform-services
    targetRevision: 87b4cdb7e9310b4663a7eb14c2623b14205b17ac
    ref: values
  - repoURL: https://openfga.github.io/helm-charts
    targetRevision: 0.2.19
    helm:
      valueFiles:
        - $values/values/services/openfga/values.yaml
        - $values/values/services/openfga/uat.yaml
      releaseName: openfga
    chart: openfga
  - repoURL: https://github.com/example/platform-services
    path: charts/defaults/openfga/resources/stages/uat
    targetRevision: d8f37d7d21c6b5ef1a823d14219cdb2902b587b2
    kustomize:
      namespace: openfga

The first source is just being used as an alias to referencing values files outside of the chart directory in the same repo. Second source is the helm chart, third are some extra resources I'd like to bundle into the application state and sync process.

Kargo 1.x.x seemingly bumped both sources to the correct revision since they matched, this time around I'm experiencing a partial failure state where only one of the sources for https://github.com/example/platform-services is matching the correct and tracked commit id - I'd like to make sure both are updated in lockstep in this scenario.

Any ideas?

[krancour]

You can update multiple sources in a single argocd-update step, but which sources to update in which ways are identified using repoURL (or in the case of a chart direct from a helm chart repo, repoURL + chart name).

You have two sources with the same repoURL and that presents a bit of a conundrum. tbh, I was somehow under the impression that Argo CD didn't permit one App to have two sources with the same repoURL. I may have been mistaken about that.

I'm actually a bit perplexed as to how your Application works. You're rendering a Helm chart with Stage-specific values.yaml and then you're doing "last mile" Stage-specific kustomizations?

I'm not too familiar with how that works exactly, but can look into it as time permits. I'm at least partially wondering if your two source with repoURL https://github.com/example/platform-services can't be combined.

[danielloader]

That's handy to know, I picked up the pattern of using a values ref to store values files in a repo outside of the chart itself from this repository when I was studying solutions pre-kargo:

https://github.com/gitops-bridge-dev/gitops-bridge-argocd-control-plane-template/tree/main/bootstrap/control-plane/addons/aws

As to what I'm doing:

• There's a public facing helm chart for OpenFGA that is one source.
• Another source is just a reference so I can store my values files somewhere and reference them in the upstream public hosted helm chart source. These values are stacked with defaults, then stage specific overlays.

So far pretty explicable.

Where it gets dicey is that often helm charts don't include resources you may need to bundle with the application - recently this has been HTTPRoutes with the gateway API superseding Ingress resources that are optionally configured via helm charts.

So in addition to the HTTPRoute I also have a CloudnativePG PostgreSQL Cluster object in a small very basic kustomization that's applied in the application and added with sync-wave annotations to sync before the upstream OpenFGA helm chart is synced and applied.

Is it a great solution? Seemingly not if it's that off piste but it served me well enough until now.

I do appreciate that having duplicate source URLs in an array of sources in Argo CD would be unpleasant to deal with though.