Notification Field Support for Workflow with repository-dispatch

[bwmills]

Greetings,

We saw this open issue, however our use case is different enough I thought a new issue (feature request) would be optimal. I'll try to explain our use case and provide sample YAML.

Use Case

We use GitHub Actions to manage CI/CD for a fairly large number of repos in support of a set of microservices that operate in Kubernetes. Since we have a multi-repo setup (a dedicated repo for each microservice) we designed our CI/CD pipelines such that the single workflow file residing in each microservice repo is as simple and uniform as possible. For example (I cannot provide the rest without redactions):

name: Build and push service image to ECR

on:
  pull_request:
    branches: [ 1.*.* ]
    types: [ closed ]
  push:

jobs:
  CI_trigger_job:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Trigger build job
        uses: peter-evans/repository-dispatch@v1
        with:
          token:  ${{ secrets.TOKEN }}
          repository: Owner/central-builds
          event-type: build_and_deploy
          client-payload: ...
        ...

The peter-evans/repository-dispatch@v1 action allows us to specify another GitHub repo where the actual build is run. Envision the snippet above as the service-1 build_service.yml that dispatches the build request to another repo named central-builds which has a more complex workflow that:

• is shared by all microservice repo workflows
• can take in client-payload attributes to drive conditional logic

The purpose of this design is to allow us to manage changes to our pipelines in a single workflow in one repo only.

Workflow with Notification Logic

The workflow file in central-builds is the one we are interested in with respect to Slack notifications, as this is the workflow that builds the image, pushes it to the ECR (or GCR) and perhaps deploys the image to a cloud environment.

Here is the notification-related snippet from that workflow:

- name: Send Notification to Slack
        uses: 8398a7/action-slack@v3.9.0
        if: ${{github.event.client_payload.build_type}} == 'basic'
        with:
          status: custom
          fields: repo,commit,author,workflow
          custom_payload: |
                  {
                    attachments: [{
                      mrkdwn_in : ["text"],
                      author_name : 'Service Build Notification ',
                      pretext : "---------------------------------------------------------------------------------------",
                      fallback: 'fallback',
                      color: '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning',
                      footer : "Sent from GitHub Actions",
                      text: ` Central build repo: ${process.env.AS_REPO } reports: `,
                      fields: [{
                        title: 'PR Merged By',
                        value: ` ${process.env.AS_AUTHOR} `,
                        short: true
                      },
                      {
                        title: 'Workflow',
                        value: ` ${process.env.AS_WORKFLOW} `,
                        short: true
                      },
                      {
                        title: 'Commit',
                        value: ` ${process.env.AS_COMMIT} `,
                        short: true
                      }
                      ]
                    	}
                    ]
                  }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.GHA_NOTIFICATIONS_WEBHOOK }}

This ^ is where we need some assistance (or perhaps our use case is a feature request). The notification surfaces in Slack, however - given our design - the commit (AS_COMMIT) field is not useful, as it links to a commit in central-builds. We would like some way to link to the commit associated with the PR that triggered the build in the service-1 repository.

[bwmills]

Greetings,

Thought I'd follow-up on this open issue.

We achieved the desired behavior by using reusable workflows. This GitHub Actions feature allows our centralized build setup (described above) to have the build be controlled by the centralized workflow but run in the microservice repo.

When a microservice repo (small, uniform workflow) gets triggered, it is now a caller workflow and the centralized workflow (in a central-builds repo) is the called workflow (with all the actions and various logic) ... with this setup, the build itself actually runs in the microservice repo ... so:

• The Actions build log resides in the repo where the code change that triggered the build occurred
• The resulting action-slack-driven notification (defined in the called workflow) now has usable links to the microservice repo, build log, and commit.

Thanks again for a great action.