How to send a notification when a change is made that doesn't result in a sync

[Niksko]

Is it possible to send a notification when a change is made that doesn't have anything to sync? An example would be adding a comment to file. This results in an update to the application, but since there is no functional change, no sync happens. What condition in a trigger should I use to notify on this event when it succeeds?

[alexmt]

It is not easy because Argo CD itself does not really know if it pushed any resource changes or not. Sync operation has unstructured kubectl apply output like deployment.apps/guestbook unchanged or job.batch/db-update created but it is not reliable.

The existing on-deployed trigger is trying to solve this issue. It "fires" when application is healthy and revision of manifest changes

  trigger.on-deployed: |
    - description: Application is synced and healthy. Triggered once per commit.
      oncePer: app.status.operationState.syncResult.revision
      send:
      - app-deployed
      when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status
        == 'Healthy'

It can be improved to use deployed images, instead of revision hash.

      oncePer: app.status.summary.images[0] # unfortunately there is no `strings.join` function to handle multiple images

[Niksko]

Hmmm ok, that makes sense. But what I've noticed is that status.operationState.syncResult.revision doesn't seem to be updated when there is a no-op like this. What I have noticed is that status.sync.revision is updated, hence the condition I created below. However this doesn't seem to be displaying the right behaviour, I'm still not getting a status on my repo, despite the fact that I can see logs in the notification controller that indicate it thinks it has sent this trigger.

Any ideas?

  trigger.on-no-op-sync: |-
    - description: Application syncing has succeeded
      oncePer: app.status.sync.revision
      send:
      - app-sync-succeeded
      when: (app.status.sync.status == 'Synced') and (not (app.status.health.status == 'Progressing'))

[Niksko]

@alexmt I think I know where my issue is. My trigger is firing as I expect, but looking at the code, the revision that is updated is the status.operationState.syncResult.revision. What I need is to update the status.sync.revision revision.

I made use of the github.revisionPath field, in my case setting it to "{{.app.status.sync.revision}}", however it appears as it it's not honoured, as in the debug output of the notification controller I can still see the API request going to /repos/<our-org>/my-repo/statuses/<revision that matches .app.status.operationState.syncResult.revision. Any thoughts? I found that github.revisionPath field by trawling through the code, but I got a little lost trying to see whether it's actually parsed from the notification template. Code is here: https://github.com/argoproj/notifications-engine/blob/f754726f03dac2577f38e0b054d8243a1712934b/pkg/services/github.go#L38, it's got the right tagging to parse it from the YAML

[Niksko]

Update: we are using an older version of ArgoCD that doesn't support the revisionPath property. Seems like this property was only added a few months ago, and doesn't appear to have made it into an ArgoCD release.

Hopefully in a future release of ArgoCD they will release this change, and then you should be able to configure:

...
    github:
      revisionPath: "{{.app.status.sync.revision}}"
      status:
        state: success
...

to make this work.

I'm going to leave this unanswered until I can confirm that this works.

[AlexAtkinson]

Application MUST NOT not be exposed to ArgoCD.
Unless of course you want to work like early Heroku, which the industry had matured well beyond by 2014.

Apps are on the left of the CICD workflow.
Apps are maintained discretely from your hosted workload concerns.
Apps should be versioned, built, tested, and released (published to Github and artifact repository) BEFORE the gitops repo gets updated.
The gitops repo is what ArgoCD watches for changes. It orchestrate your hosted workload environments. The interaction there is ideally automated, coming from your application CICD workflows. Ie: The foo app has released v9.0.210 successfully, and as a final step updates the gitops repo to have that version deploy to the DEV env.

With this approach, you can commit code application code changes, and only affect updates to the hosted envs when a release is made. See "trunk based branching" for more.
If you're not building firmware, or mobile, installed applications, you should be using TBD and build once strategies.

See this Github action for more.
https://github.com/marketplace/actions/gitops-automatic-versioning

Note: Do not deploy "latest" image tags... It's a red flag against operational maturity. See "build one, deploy many" postures.