[Notifications] Make GH Check Runs part of ArgoCD Notifications natively

[tijmenstor]

Summary

ArgoCD Notifications currently support the following GitHub notification bits out of the box:

• Deployment status
• Commit status
• Pull request comment

Since this was created, GitHub has introduced the check runs, which is essentially commit statuses on steroids. This will allow us to have more customizability on reporting back to GitHub and start making use of check suites as well. This is a great SO answer explaining the differences between commit statuses and check runs (and check suites).

Motivation

At my current company, we are making use of ArgoCD and ArgoCD notifications for the deployment process. In an effort to split off the CI from the CD, we want CI to only build and test, after which ArgoCD takes care of the deploying and reporting back on the status. However, some of the projects have testing to be ran after deployments are up-and-running, referring to them as post-deployment.

As of now, we deploy a monorepo with groups of services that depend on each other. When we deploy such a group, there is a possibility that a service has a post-deployment stage that needs to be ran. However, we usually deploy these groups of services together, because they have changes that depend on each other. So we can only start the post-deployment stage(s) after each and every service has been deployed correctly. Here lies the problem.

Since we split up the CI and CD, once we get to CD, we lose the ability to track whether we deploy in groups; we simply deploy a service and it reports back to GitHub. Thus, we end up with a bunch of commit statuses telling us that we deployed service X, Y and Z correctly. Now technically we could have a workflow running that checks whether all of the commit statuses with a certain name are green and then execute the post-deployment, but that would be highly inefficient and costly. What we would rather have, is check runs and check suites.

If we were to create check runs, instead of having a workflow that keeps polling the status, we could have a workflow that is triggered whenever a check suite completes, which makes it way more efficient and less costly. It will also allows us to extend the information of the deployment towards the GitHub UI through Markdown, which is a big plus.

Another big motivation behind this proposal is that GitHub itself notes that the check runs API can only be used to write to using a GitHub App, which is impossible to do with ArgoCD Notifications without native support. Link to GH API docs

Proposal

We can add the check runs possibility side-by-side with the commit statuses. They are different APIs and can be used independently of each other. I think most, if not all of the possible values of creating a check run can be implemented and passed potentially. We can also start off simple and add only the basics, such as details_url, status, conclusion and output, implementing things like actions et cetera at a later stage.

The standard overview of possibilities look like the following now:

template.app-deployed: |
  message: |
    Application {{.app.metadata.name}} is now running new version of deployments manifests.
  github:
    repoURLPath: "{{.app.spec.source.repoURL}}"
    revisionPath: "{{.app.status.operationState.syncResult.revision}}"
    status:
      state: success
      label: "continuous-delivery/{{.app.metadata.name}}"
      targetURL: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
    deployment:
      state: success
      environment: production
      environmentURL: "https://{{.app.metadata.name}}.example.com"
      logURL: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
      requiredContexts: []
      autoMerge: true
      transientEnvironment: false
      reference: v1.0.0
    pullRequestComment:
      content: |
        Application {{.app.metadata.name}} is now running new version of deployments manifests.
        See more here: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true

I propose to expand it to:

template.app-deployed: |
  message: |
    Application {{.app.metadata.name}} is now running new version of deployments manifests.
  github:
    repoURLPath: "{{.app.spec.source.repoURL}}"
    revisionPath: "{{.app.status.operationState.syncResult.revision}}"
    status:
      state: success
      label: "continuous-delivery/{{.app.metadata.name}}"
      targetURL: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
    deployment:
      state: success
      environment: production
      environmentURL: "https://{{.app.metadata.name}}.example.com"
      logURL: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
      requiredContexts: []
      autoMerge: true
      transientEnvironment: false
      reference: v1.0.0
    pullRequestComment:
      content: |
        Application {{.app.metadata.name}} is now running new version of deployments manifests.
        See more here: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true
    checkRun:
      # head_sha would be the revisionPath
      name: "continuous-delivery/{{.app.metadata.name}}"
      details_url: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
      status: completed
      conclusion: success
      started_at: "YYYY-MM-DDTHH:MM:SSZ"
      completed_at: "YYYY-MM-DDTHH:MM:SSZ"
      output:
        title: "Deployment of {{.app.metadata.name}} on ArgoCD"
        summary: "Application {{.app.metadata.name}} is now running new version of deployments manifests."
        text: |
          Application {{.app.metadata.name}} is now running new version of deployments manifests.
          See more here: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true

Simply as a start!

[anandf]

Does this require an enhancement proposal to work on ? IIITB students are interested to work on this issue.

[tijmenstor]

@anandf as far as I am concerned, no. I have not worked on this yet primarily because I feel it would be a waste to spend a lot of effort into this feature if it's not something that needs or should be added. I must admit, it has slipped my mind as well in the mean time. In any case, if there are students interested in working on it, why not? It'd be a great learning example and depending on reviews, meaning their first addition into the ArgoCD ecosystem. Otherwise I'll look to ping one of the maintainers soon to get an update and work on it myself.

[tijmenstor]

Implementation done in argoproj/notifications-engine#341