Helm chart + values files from Git

[evgf]

Hello everyone,

we are trying to migrate our CD processes to ArgoCD and faced an issue where I really need some input. (Checked the official documentation and threads here but seems like there is no answer.)

Our typical scenario is:

• Helm charts available via Git or as a remote Hem Repo
• values-file or files, specific to the service & stage, available in Git.

What we want to achieve:

• When the values-file gets updated, ArgoCD synchronises the environment using the Helm chart + this values files.

Should be pretty common scenario, I believe.

Here are the issues that we're facing when implementing it using ArgoCD:

1. There is no way (or at least we did not find any) to use two Repos - one for the Chart and one for the values file. Although we only need to monitor the changes in the values-file(s) and not in the chart.

2. If we fully rely on Git and store the charts & values for all stages in a single repo, there is no way to separate the chart versioning per stage. So I cannot deploy the "UAT" stage using the chart v. 1.1.1 while retaining the "Prod" stage using the chart v. 1.0.0.

3. If we use separate Git branches to store charts + values for individual stages, there is no single Repo for the chart (all charts are stored per-stage) so no process of testing one chart version in Stage and then moving it to Prod.

4. If we rely on Helm support in ArgoCD 1.3 (looks promising) and pack the values files inside the Helm Repo, we need to re-index it every time the values file changes (Git push + WebHook + CI/CD re-index - exactly what we want to avoid when moving to ArgoCD). Also, the repository server seems not re-indexing the Helm-Repo with the existing "targetRevision" and we need to re-start it to get the latest Helm Repo downloaded. If we increment the Helm Repo version for every change of the values-file, we need to adjust the targetVersion field in the Application + this is sort of against the Helm philosophy to include & version the values-files in the Helm Repo.

Am I missing something in this picture?
How would / do you implement such a scenario?

Kind Regards,

[OmerKahani]

Just as an input, we are doing number 2. Most of the time staging and prod are the same so we only use one branch.

If we need to change the chart, we change the application in argocd to use a branch. That way staging will point to a branch. and once the change is good we merge back to master (and deploy to production)

[alexec]

You should be able to configure a values file from the UI that is a URL itself. Have you tried that?

It's unlikely we'll be able to support both Git+Helm repo, but you could also use a requirements.yaml in a Git repo to do this.

[evgf]

Hi @alexec, thank you for your answer.
Yes, I've seen this opportunity but it cannot solve this problem. There is no real need to support two Git Repos - let me explain the most typical Helm scenario:

Normally, the CI solution builds a new image and manages the values-file that includes a tag for this newly built image. It then uses Helm to retrieve the Helm Chart from a remote Helm Repo and provides this values file to install / upgrade the application.

Moving to CD, we need to observe the values-file in Git for changes and apply it together with the remote Helm Repo in case of any change.
Monitoring of the Helm-chart itself is not necessary as soon as we rely on a particular version which is configured in the Application CRD (as you do it in 1.3).

How would you implement this scenario using ArgoCD?

[alexec]

For you use case I’d try creating a Git repo with a Helm chart in it. That would have a values file you could update, and import the main Helm chart using requirements.yaml.

Alternatively, you CI could use the Argo CD CLI (or API) to update the image.

Another way, store the App manifest in Git (aka “declarative”) and your CI modifies that.

[evgf]

I'm currently implementing the option nr. 1 although the problem is that we have a Helm Chart which is used in 30+ Services and each of them is customized for 3 possible environments.

Replicating this Chart 30 times without a centralized Repo looks dirty. Can be a show stopper for the whole migration.

Modifying the Application definition is not an option since the whole goal is to reduce the rights that the CI-solution has. Giving it the right to update all Application-definitions from various teams in the argocd namespace is a a hard thing to convince people with.
Or you mean something different?

[evgf]

The actual plan is to separately pull the Helm Chart Repo and the values Repo on the CI-solution and then push both of them as a consolidated Chart to the "Stage" Repo / Branch.
Not ideal but should resolve the major issue.

[cronik]

I have a similar use case in trying to adopt Argo in our organization. We have many application (100's) using a common chart that is published to Artifactory which serves as our helm repository. The values files are stored in each app's repo. Having each app add a chart to their repo is not really practical at scale.

I was going to attempt to work around this using a configManagementPlugin along the lines of:

# NOTE: this hasn't been tested and almost certainly doesn't work
configManagementPlugins: |
  - name: myrepo-charts
    init:
      command: ["/bin/sh", "-c"]
      args: 
      - |
        helm init --client-only --skip-refresh \
        && helm repo rm stable \
        && helm repo add myrepo https://artifactory.example.com/artifactory/helm \
        && helm repo update \
        && helm fetch --untar --untardir charts --version $CHART_VERSION myrepo/$CHART_NAME

    generate:
      command: [sh, -c]
      args: ["helm template charts/$CHART_NAME -f $CHART_VALUES"]

Ideally there is a native solution for this case where we could do something like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-dit
spec:
  project: default
  source:
    repoURL: https://bitbucket.example.com/scm/foo/myapp.git
    targetRevision: HEAD
    path: ""
    helm:
      repoURL: https://artifactory.example.com/artifactory/helm
      chart: "web-service"
      chartVersion: "1.0.0"
      valueFiles: ['values-dit.yaml'] # resolved against source.repoURL and source.path

[rbkaspr]

@cronik Your solution actually works just fine, with some modifications. Here's a generalized version of my solution:

Added this plugin to argocd-cm

data:
  configManagementPlugins: |
    - name: helm-resolver
      init:
        command: [bash, -c]
        args: ["helm repo add <repoName> <repoURL>
      generate:
        command: [bash, -c]
        args: ["helm template -n $ARGOCD_APP_NAMESPACE --values values.yaml $ARGOCD_APP_NAME <chart> --version CHART-VERSION"]

And then created a Git repo that contains only the values file for overrides. My application spec for one of these apps would look like so:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sample-app
  namespace: argocd
spec:
  destination:
    namespace: sample-namespace
    server: https://kubernetets.default.svc
  project: default
  source:
    path: .
    plugin:
      env:
        - name: CHART_VERSION
          value: 1.0.0
      name: helm-resolver
    repoURL: [email protected]/sample-app

Now I'd still say it'd be nice to have this sort of option more natively available in ArgoCD, but this appears to be a valid workaround at this time.

Tested and verified on v1.5.0-rc1

[matus-m]

The inability to pass external values.yaml files to helm charts is a real pain. Maybe it could also be solved by propagating values from app-of-apps(which is goign to have git as source) down to the ,,children" argo crds(whose source is helm rep). We can do it via templates, but it is very error prone and laborious to keep in sync if you have lot of apps deployed.

[franklevering]

Would this be a feature that might get supported by the ArgoCD team? We are facing a similar issue where we are trying to install an external Helm chart, but having our values.yaml in our Git repository. The version of the Helm Chart we are using won't be updated a lot, however, the values that we are passing to the Helm chart might change more often. Therefore we are versioning the values file within our repository and we prefer ArgoCD to update the Helm chart whenever the version of the values changes.

I'm happy to start working on a PR for this. However, I am not too familiar with the internals of ArgoCD so I would need some guidance on that. Also, it's good to know if this feature will make it to a stable release before I start working on anything.

[jannfis]

@franklevering Sourcing an application from two (or more) repositories would be a major design change to many components in ArgoCD. It would also introduce a lot of challenges to be solved, and a lot of questions to be answered.

Having just read the thread in this issue, and considering many of the cons outspoken for original solution number 2, I would at least consider the following scenario:

• Get the Chart.yaml in a Git repository
• Get the values.yaml in another, application specific Git repository
• Connect both repositories by including the repository containing Chart.yaml as a Git sub-module to the application specific Git repository
• Create the ArgoCD application from the application specific repository

This way, both assets - Chart.yaml and application specific values.yaml can have their own life-cycles. By smart tagging or branching of Chart.yaml repository and appropriately including it as a sub-module, most if not all use-cases could be covered.

Working with Git submodules is supported since ArgoCD v1.4 (see https://argoproj.github.io/argo-cd/user-guide/private-repositories/#git-submodules).

What do you guys think about this?

[franklevering]

@franklevering Sourcing an application from two (or more) repositories would be a major design change to many components in ArgoCD. It would also introduce a lot of challenges to be solved, and a lot of questions to be answered.

Having just read the thread in this issue, and considering many of the cons outspoken for original solution number 2, I would at least consider the following scenario:

• Get the Chart.yaml in a Git repository
• Get the values.yaml in another, application specific Git repository
• Connect both repositories by including the repository containing Chart.yaml as a Git sub-module to the application specific Git repository
• Create the ArgoCD application from the application specific repository

This way, both assets - Chart.yaml and application specific values.yaml can have their own life-cycles. By smart tagging or branching of Chart.yaml repository and appropriately including it as a sub-module, most if not all use-cases could be covered.

Working with Git submodules is supported since ArgoCD v1.4 (see https://argoproj.github.io/argo-cd/user-guide/private-repositories/#git-submodules).

What do you guys think about this?

I understand your approach with Git submodules. However, after browsing through the ArgoCD examples we found another way to achieve what we want (https://github.com/argoproj/argocd-example-apps/tree/master/helm-dependency).

Instead of using git submodules, we can just create a Chart.yaml in our application specific Git repository. This Chart.yaml only has a dependency, which is the actual Helm chart we want to install. That way, we can monitor the application specific Git repository for changes and update the Helm chart. This would work for both external as well as self-created Helm charts.

[jannfis]

Awesome, @franklevering - this is actually even simpler! Thanks for sharing this solution.

[bnutt]

@franklevering Were you able to get this case to work? Trying to pass my own valuesFile in git and its in the same directory as where the Chart.yaml is specificed. The Chart.yaml also has a dependencies section in it to reference the chart to be deployed and its repo. Currently it templates the chart, but keeps falling back to the default values, even if the app shows that it loaded the custom values file into Argo CD.

[amkartashov]

helm dependency is w/a, and it's not complex, but

• it feels awkward
• values file differs from manual deployment of the same chart (and not only by moving dependency values under chart-name: , because tags and conditions are always taken from the top chart)

I like proposal for extending helm source type here #2789 (comment) - in addition it would be good to have option to change chartVersion as a parameter, and also it might be needed to modify source type detection so ArgoCD sees that this is an external helm package.

[laurentzoz]

Hello, this is my use case:

• argocd 1.5.1
• Google Kubernetes Engine cluster
• I host a helm repo on a private GCS bucket, with a publicly accessible index.yaml
• helm API v2
• I made a custom image containing https://github.com/hayorov/helm-gcs, to access the private repo
• I use the helm dependency model: all my charts are in a github monorepo, master branch only. Chart versioning is done by the helm repo. The final values files are on github using the following hierarchy:

deployments
-- dev
---- app1
------ Chart.yaml
------ values.yaml
-- prod
---- app1
------ Chart.yaml
------ values.yaml

This is where things become weird: this setup works in local and even in the repo-server container with kubectl exec + helm dependency build. helm template also works.

But impossible to make it work going through the regular way, I get the error
level=error msg="`helm dependency build` failed exit status 1: Error: could not find : chart frontend-react not found in gs://my-helm-chart-repo"
At first I was thinking about a basic permission issue between GCS and the helm plugin but doing the commands manually works like a charm 🤔
Is it because I open a shell or something ? I'm not really sure it's argocd related at this point.

EDIT:
I finally got it to work ! I read #1105 and #1153 which pointed me to the environment variable HELM_PLUGINS, the directory where the plugins should live. Using helm3 and my custom install, it's /home/argocd/.local/share/helm/plugins/ but YMMV
I simply added this env var directly in the repo-server deployment, nothing more !

[psionikangel]

@franklevering Were you able to get this case to work? Trying to pass my own valuesFile in git and its in the same directory as where the Chart.yaml is specificed. The Chart.yaml also has a dependencies section in it to reference the chart to be deployed and its repo. Currently it templates the chart, but keeps falling back to the default values, even if the app shows that it loaded the custom values file into Argo CD.

I also tried the same thing and altough my app was deployed, the custom values were not taken into account.

[test-account-0]

Also You can embed values in application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: fluent-bit-stable
  namespace: ops
spec:
  project: default
  source:
    repoURL: https://kubernetes-charts.storage.googleapis.com
    chart: fluent-bit
    targetRevision: 2.8.12
    helm:
      values: |
        image:
          fluent_bit:
            repository: fluent/fluent-bit
            tag: 1.3.8
            pullPolicy: Always
        metrics:
          enabled: false
  destination:
    server: https://kubernetes.default.svc
    namespace: ops
  syncPolicy:
    automated:
      selfHeal: false

but option to have separate file in the same directory as application file would be better.

Getting values file from helm repo is something almost never used.

[musabmasood]

In the same boat. Our situation is something like this.

We followed the best practices of keeping k8s config separate from the app repo, so we have these (hypothetical) repos:

argocd-repo
This repo contains argocd declarative setup manifests, secrets etc. Basically to install argocd on our argocd cluster. Apart from that, this repo also contains a special custom helm chart helm-bootstrap-project which I will talk about later.

myapp-repo
This is the application repo for our "myapp". It contains the actual code and Dockerfile. The CI for this repo builds/tags/pushes the image and creates a commit in the myproject-repowhere it updates helm-myapp chart's values.yaml with the new tag.

myproject-k8s-repo
This repo contains the chart helm-myapp and multiple value files for its deployment on different clusters.

Process:

• Developers develop on the myapp-repo and everytime there is a new merge-to-master myproject-repo/charts/helm-myapp should get updated with the latest version
• SREs maintain myproject-repo with helm charts and their value files for different environments
• SREs also maintain the argocd-repo and the common helm-bootstrap-project chart inside it

Apart from that, developers can occasionally create PRs on myproject-repo but they need SRE approvals.

The helm-bootstrap-project chart

When we have a new project or tenant, we wanted a simpler process to onboard it into argocd. This chart templates all the Applications, AppProjects and clusters etc for a new tenant. In the case above, our tenant is myproject so we deploy this chart with a values file something like this:

projectName: myproject
clusters: {...}
mainRepo: myproject-repo.git
deployments:
  staging:
   # by convention, looks for the helm chart in myproject-repo.git/charts/
   # by convention, uses the value file myproject-repo.git/env/staging/helm-myapp.yaml
    - helm-myapp
  prod:
   ...
...

So ideally for the myproject tenant, we just want to create a file argocd-bootstrap.yaml with the above configuration and keep it in the root of myproject-repo.git. We are struggling to find the best solution as well. Some options:

1. myproject-repo.git/argocd-bootstrap.yaml can be an ArgoCD Application CRD with values embedded inside it, and uses the remote helm-bootstrap-project chart. Not really a fan of embedding values.
2. Create a helm chart myproject-repo.git/charts/argocd-bootstrap which uses helm-bootstrap-project as a dependency. Again, it looks awkward.
3. Clone the helm-bootstrap-project chart into myproject-repo.git, which defeats the whole purpose of the common chart
4. Create tenant value files within the argocd-repo, this way they live with the helm-bootstrap-project chart
5. Do something like Helm chart + values files from Git #2789 (comment)
6. Use remote values file in the valueFiles parameter

Currently we are doing (4) but the value files change more frequently than the common chart, and we dont want developers to create PRs on the argocd-repo.

The thing with (1), (2) and (3) is that we would like our rendered manifests to auto-update when we make a change to the common chart. I guess with (2) we can use semantic versioning or something.

(5) and (6) is also interesting but we haven't tried it yet.

By the way ArgoCD is awesome, great work guys! 💯

---

Update: We tried remote value files (6) with raw github URL. Its not helpful as the Application is not able to track new changes if they are only on the values file.

[Romiko]

You should be able to configure a values file from the UI that is a URL itself. Have you tried that?

It's unlikely we'll be able to support both Git+Helm repo, but you could also use a requirements.yaml in a Git repo to do this.

Thanks, we got this working nicely with the prometheus operator :)

Awesome work on this project!

[OmerKahani]

It's unlikely we'll be able to support both Git+Helm repo, but you could also use a requirements.yaml in a Git repo to do this.

we use requirements.yaml in all of our charts, the charts that ArgoCD uses are just value files and requirements.yaml that reference to the "real" chart, this also helps when we want to add objects as we can just add a templates folder to our chart.

[Romiko]

Hi,

I think this issue can be closed. Here is the solution.

• A requirments.yaml in your components folder./components/mycomponent/requirements.yaml
• The root element of all your values files e.g ./components/mycomponent/values.yaml must contain the remote chart name

Examples

./components/nginx-ingress/values-tools.yaml
nginx-ingress: controller:

./components/nginx-ingress/requirements.yaml
`
dependencies:

• name: nginx-ingress
  version: "1.39.0"
  repository: https://kubernetes-charts.storage.googleapis.com/
  `

Sample ScreenShot

[Romiko]

It's unlikely we'll be able to support both Git+Helm repo, but you could also use a requirements.yaml in a Git repo to do this.

we use requirements.yaml in all of our charts, the charts that ArgoCD uses are just value files and requirements.yaml that reference to the "real" chart, this also helps when we want to add objects as we can just add a templates folder to our chart.

Yeah, we just did this now, the only catch was adding the chart name as a root element to all value files. my last post for an example.

[jetersen]

@Romiko please copy paste the screenshot to github, it will take care of markdown and uploading it 👍
Also use of triple backticks would be appreciated

```yaml
nginx-ingress:
  controller:
```

```yaml
dependencies:
- name: nginx-ingress
  version: "1.39.0"
  repository: https://kubernetes-charts.storage.googleapis.com/
```

(Hint four ```` backticks allow you do the above)

This produces:

nginx-ingress:
  controller:

dependencies:
- name: nginx-ingress
  version: "1.39.0"
  repository: https://kubernetes-charts.storage.googleapis.com/

[test-account-0]

@Romiko I might not understand something. What is new in Your approach?

[sdelrio]

@sdelrio have you installed the 2.6.0-rc1 ApplicationSet CRD? All the necessary changes should already be in place.

I just put this into helm values, you're right, the CRDs wont be updated since helm chart doesn't have the new ones

argo-cd: 
  global:
    image:
      tag: v2.6.0-rc1

This won't upgrade the CRDs.

Will manually update with https://github.com/argoproj/argo-cd/tree/master/manifests/crds and test again. Thanks!

[sdelrio]

@crenshaw-dev all went fine with with ApplicationSet CRD thanks for help.

Also updated to v2.6.0-rc2 and after that just had to add the CRDs an make a workaround until #11796 issue is fixed, adding pathParamPrefix: in the generators git.

[dllegru]

@crenshaw-dev

Using this thread to post a series of issues we've seen when evaluating this FEAT in v2.6.0-rc2.
Issues are somewhat similar in some cases, so probably are happening by the same root case, just stating them anyway to cover all cases. Also one of the issues has already been mentioned in this thread.

When using the following Application definition:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: infrastructure-labs-exercise
  namespace: argo-cd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  sources:
    - repoURL: https://github.com/xxxx/infrastructure-labs
      targetRevision: SPIKE/tests
      ref: myRepo
    - repoURL: https://charts.bitnami.com/bitnami
      targetRevision: 13.2.21
      chart: nginx
      helm:
        valueFiles:
          - $myRepo/argo-cd-exercises/nginx-values-10/values.yaml
  destination:
    name: in-cluster
    namespace: daniel-tests
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false

Doing the following evaluations:

---

1 - Deploying from scratch

We will evaluate doing a deployment from a scratch as a new Application into the destination cluster.

• Evaluation:
  • Status: ✅⚠️ (works with inconsistency state errors until refreshed)
  • It works as expected, deploying the chart defined in the sources: with the configuration defined in the values.yaml
  • An issue happens within Argo CD showing inconsistency as the Application it is indeed deployed into the cluster but being shown as status status: OutOfSync & health: missing in Argo CD.
• Issue - inconsistency:
  • Application gets created, but the state is shown as status: OutOfSync & health: missing both in Argo GUI and object status
• Fix issue - inconsistency:
  • It gets fixed by clicking in Refresh button in the Argo CD application GUI or by cli argocd app get infrastructure-labs-exercise --refresh

---

2 - Modify parameters of values.yaml after the Application is deployed & running

We will evaluate modifying parameters of the sourced values.yaml when the Application is already deployed, running and in Healthy state.

The repository containing the sourced values.yaml has a webhook configured towards Argo CD which should automatically trigger the Application sync with the new value changes.

• Evaluation:

  • Status: ❌ (non functional)
  • Changes pushed at values.yaml are not picked up by Argo CD automatically.
  • Manual intervention has to be done in order to pick up the new values.

• Issue - not syncing with modified values.yaml:

  • After committing and pushing changes into the defined & tracked $myRepo values.yaml branch the Application does not get synced with the new values. Argo CD does not detect it and does not trigger any change in the Application.
    • We changed replicaSet: 2 for replicaSet: 5
  • It does not matter if we even have webhooks enabled or waiting for the default sync timer.
  • Doing an Application SYNC or REFRESH does not update the values.yaml into the Application deployed.
  • Application it is being shown as Healthy and Synced when is not true.

• Fix - not syncing with modified values.yaml:

  • Gets fixed running a --hard-refresh either by GUI or CLI
  • After running the —hard-refresh it does fix the issue as now the Application has updated its values and increasing pods to 5 replicas as defined in the values.yaml, this also being reflected in the GUI.
  • Although, a new sub-issue happens after this, which is that the Application is being now shown as OutOfSync in both gui and cli.
  • This sub-issue gets fixed running a --refresh into the Application, seems related to the Issue - inconsistency mentioned in the first case.

---

3 - Modify the Application definition after it is deployed & running

We will evaluate modifying definition of the resource Application itself after is already deployed, running and in Healthy state.

We tested modifying both parameters at sources: either using a different Helm Chart version (targetRevision) and/or changing valueFiles repository folder/file.

We modified the Application updating a local yaml definition file then updating it in the cluster running kubectl apply -f application.yaml

• Evaluation:

  • Status: ✅⚠️ (works with inconsistency state errors until refreshed)
  • It works as expected, after applying changes into the defined Application cluster resource, Argo CD does apply the new values.
  • An issue happens within Argo CD showing inconsistency as the Application it is indeed updated and applied with the new definition into the cluster, but being shown as status: OutOfSync & health: missing.

• Issue - inconsistency:

  • Application gets updated and new changes applied, but the state is shown as status: OutOfSync & health: missing both in Argo GUI and object status

• Fix issue - inconsistency:

  • It gets fixed by clicking in Refresh button in the Argo CD application gui or by cli argocd app get infrastructure-labs-exercise --refresh

---

4 - Delete the Application , change values.yaml and recreate Application

We will evaluate delete a deployed & running Application, modify parameters in the original source values.yaml and create again the Application

• Evaluation:
  • Status: ❌ (non functional)
  • When the Application gets created again, it is created with the previous values.yaml parameters.
  • Application being shown as status status: OutOfSync & health: missing in Argo CD.
  • Manual intervention has to be done in order to pick up the new values.
• Issue - inconsistency & old values.yaml parameters deployed:
  • Application gets deployed with previous values.yaml
  • State is shown as status: OutOfSync & health: missing both in Argo GUI and object status
• Fix issue - inconsistency:
  • Gets fixed running a --hard-refresh either by GUI or CLI
  • Similar sub-issue as case 2 happens, we have to run a --refresh again to have a fully synced and healthy Application

[lsoica]

I've encountered the second issue mentioned here #2789 (comment) as well.
Are these issues tracked anywhere ?

[driosalido]

This is my experience using 2.6.1

Using #2789 as reference this is what I see:

1 - Same Issue. The application is deployed but no change of status until refresh
2 - Not exactly the same problem. ArgoCD pick the change and apply it, but not status change until refresh (no hard refresh needed)
3- Same behaviour
4 - Same issues with status and health until refresh , but the application was created with the the right values

[adrianmiron]

My main issue is it's not picking up changes from all the sources, a manual sync is needed.

[APemberton1]

Now we have multiple sources is there a way to use build env vars from the first source as part of the second. E.g.

  sources:
    - repoURL: https://github.com/xxxx/repo-1
      targetRevision: main
      ref: repo-1
    - repoURL: https://somecharturl.com
      targetRevision: 1.0.0
      chart: somechart
      helm:
        valueFiles:
          - $repo-1/values.yaml
         parameters:
         - name: image.tag
            value: ${ARGOCD_APP_REVISION}

ARGOCD_APP_REVISION resolves to 1.0.0 whereas I want it to resolve to the revision from repo-1 which I manage. Is there a way to do this currently? Would be very useful as part of automated image version tagging

[vl-kp]

Now we have multiple sources is there a way to use build env vars from the first source as part of the second. E.g.

  sources:
    - repoURL: https://github.com/xxxx/repo-1
      targetRevision: main
      ref: repo-1
    - repoURL: https://somecharturl.com
      targetRevision: 1.0.0
      chart: somechart
      helm:
        valueFiles:
          - $repo-1/values.yaml
         parameters:
         - name: image.tag
            value: ${ARGOCD_APP_REVISION}

ARGOCD_APP_REVISION resolves to 1.0.0 whereas I want it to resolve to the revision from repo-1 which I manage. Is there a way to do this currently? Would be very useful as part of automated image version tagging

anyway to ref the key/values for the parameters

[crenshaw-dev]

Accessing the build environment of another source is currently not supported. Would you mind opening a new enhancement request?

[APemberton1]

Raised enhaccement request: #14855

[codechirag123]

Hi @vl-kp, I'm new to ArgoCD. Following your comment I updated my manifest application as I want to deploy public helm charts with my own custom-values managed in Git. Can you take a look at my application manifest and help me with what is wrong in it.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app
spec:
  destination:
    name: ''
    namespace: portainer
    server: 'https://kubernetes.default.svc'
  source:
    repoURL: 'https://portainer.github.io/k8s/'
    chart: portainer
    helm:
      valueFiles:
        - $values/helm/monitoring/portainer/prod-custom-values.yaml
  sources:
    - repoURL: 'https://portainer.github.io/k8s/'
      chart: portainer
      helm:
        valueFiles:
          - $values/helm/monitoring/portainer/prod-custom-values.yaml
    - repoURL: 'https://bitbucket.org/wishboxteam/duve-staging-k8s.git'
      targetRevision: HEAD
      ref: values
  project: portainer

I did not understand what to put in the source: section when I have provided everything in the sources: section. So I adde the helm chart repo for portainer.
The error that I receive is this:

Unable to create application: application spec for app is invalid: InvalidSpecError: Unable to generate manifests in : rpc error: code = Unknown desc = invalid revision '': improper constraint:

@dllegru do you have any opinion about this?

[alekseydemidov]

Hello, @codechirag123,
first of all, you don't need to use source and sources at the same time, only sources will be enough.
secondly, if you use helm repo, you have to set up 'targetRevision'
for instance:

  sources:
    - repoURL: 'https://portainer.github.io/k8s/'
      chart: portainer
      targetRevision: portainer-1.0.46
      helm:
        valueFiles:
          - $values/helm/monitoring/portainer/prod-custom-values.yaml
    - repoURL: 'https://bitbucket.org/wishboxteam/duve-staging-k8s.git'
      targetRevision: HEAD
      ref: values
  project: portainer

targetRevision is usually equal repository tag (https://github.com/portainer/k8s/tree/portainer-1.0.46/charts/portainer)

[JordanYefet]

We're having the same issues as @dllegru has mentioned above.
Is there a workaround for fixing the syncing/refreshing issues? I'm clueless.

[MohammedNoureldin]

Is the issue in point 2 mentioned by @dllegru still there? I.e., doesn't modifying the values.yaml file for a running application is recognized as out of sync?

@JordanYefet, I am wondering if you also mean the issue in point 2.

[JordanYefet]

@MohammedNoureldin
Updating the values.yaml file that is found in a different git repo doesn't trigger the argoCD application, I have to manually press the refresh twice - one for acknowledging the changes, the next one actually to apply them.

Argo version: v2.6.1+3f143c9
Build Date: 2023-02-08T18:51:05Z

Maybe is the version too old and has already been fixed in newer versions?

Current workaround:
Instead of using multiple sources, I use a single-source git repo that contains an umbrella chart. Works like a charm, but is harder to maintain.

[MohammedNoureldin]

@JordanYefet I gave it a try yesterday, and it seems to be working. I use no Git hooks, just relying on Argo CD to pull the changes, after waiting a few minutes, it triggers a sync process and the changes are also deployed.

Probably it is your version, I am using the latest, 2.8.4

[zbloss]

Is it possible to point the source of my helm chart to a private github repository? I have two repos, one holds my helm charts and the other holds my values.yaml files both repos have been added w/ SSH Keys to ArgoCD.

[abdennour]

any update ?

[Keramblock]

any update ?

Issue was fixed more then 6 months ago. What update you are waiting for?