Argo CD Notifications: Failure to get commit metadata

[andrea-mosk]

Describe the bug

I'm experiencing problems when sending notifications with a template using the repo.GetCommitMetadata function.

I have Argo CD set up in my local Kubernetes cluster (I'm using minikube), and I am sending notifications to a specific URL (so using the Webhook service). The body of the template looks like the following:

{
  "app": {{toJson .app}},
  "context": {{toJson .context}},
  "commit_metadata": {{toJson (call .repo.GetCommitMetadata .app.status.operationState.syncResult.revision)}}
}

I have an Argo CD application that is monitoring a private repository (the connection is done via GitHub PAT) and sending notifications with this template. When I sync via the Argo CD UI, the notification is successfully sent (both if I do a manual sync or if I push something to the repo and I click “refresh”). However, for the normal ArgoCD sync (i.e. I push something on the repository and I wait for Argo CD to detect the changes), the notification is not sent (or it is, but after a lot of time).

I looked into the logs of the argocd-notification-controller pod and I saw that it’s unable to execute the GetCommitMetadata call for this error (full logs below):

at <call .repo.GetCommitMetadata .app.status.operationState.syncResult.revision>: error calling call: rpc error: code = Internal desc = Failed to fetch default: git fetch origin --tags --force --prune failed exit status 128: fatal: could not read Username for 'https://github.com/': terminal prompts disabled"

Does anyone have some guidance on this? Maybe I do have something not properly configured in the connection but I’m unsure on why the “refresh” from the UI works and the normal auto sync doesn’t.

Version

argocd: v2.9.2+c5ea5c4.dirty
  BuildDate: 2023-11-20T18:19:21Z
  GitCommit: c5ea5c4df52943a6fff6c0be181fde5358970304
  GitTreeState: dirty
  GoVersion: go1.21.4
  Compiler: gc
  Platform: darwin/arm64
argocd-server: v2.6.7+5bcd846

Logs

time="2023-12-15T11:21:45Z" level=info msg="Start processing" app=argocd/example-server-argocd-application
time="2023-12-15T11:21:45Z" level=info msg="Trigger on-sync-succeeded result: [{[0].8NN1tOzKoTpzYKMQrfnavRKZ_So  [ci-visibility-template] true}]" app=argocd/example-server-argocd-application
time="2023-12-15T11:21:45Z" level=info msg="Sending notification about condition 'on-sync-succeeded.[0].8NN1tOzKoTpzYKMQrfnavRKZ_So' to '{ci-vis-webhook }'" app=argocd/example-server-argocd-application
time="2023-12-15T11:21:45Z" level=error msg="Failed to notify recipient {ci-vis-webhook } defined in app argocd/example-server-argocd-application: template: ci-visibility-templateci-vis-webhook:6:31: executing \"ci-visibility-templateci-vis-webhook\" at <call .repo.GetCommitMetadata .app.status.operationState.syncResult.revision>: error calling call: rpc error: code = Internal desc = Failed to fetch default: `git fetch origin --tags --force --prune` failed exit status 128: fatal: could not read Username for 'https://github.com': No such device or address" app=argocd/example-server-argocd-application
time="2023-12-15T11:21:45Z" level=info msg="Processing completed" app=argocd/example-server-argocd-application

[AndrasSandor]

I've been struggling with the same issue when trying to use call .repo.GetCommitMetadata to send webhook notifications for specific PRs only in a monorepo.

[AndrasSandor]

one thing I found is you have to specify the fields you want to call in repo.GetCommitMetadata this template should filter the commit message

template.prod-app-deployed: | webhook:
form: method: POST body: | { {{ $commitMessage := (call .repo.GetCommitMetadata .app.status.sync.revision).Message }} {{ if contains "Release to production" $commitMessage }} "text": "{{ .app.metadata.name }} has been deployed to production. Health Status: {{ .app.status.health.status }}." {{ end }} }

[andrii-korotkov-verkada]

ArgoCD versions 2.10 and below have reached EOL. Can you upgrade and let us know if the issue is still present, please?

[AndrasSandor]

@andrii-korotkov-verkada I started using the below workaround as per above and it served the same purpose.