Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification Field Support for Workflow with repository-dispatch #165

Open
bwmills opened this issue Oct 25, 2021 · 1 comment
Open

Notification Field Support for Workflow with repository-dispatch #165

bwmills opened this issue Oct 25, 2021 · 1 comment
Labels
help wanted Extra attention is needed

Comments

@bwmills
Copy link

bwmills commented Oct 25, 2021

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/[email protected]
        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 bwmills changed the title Notification Field Support for Workflow with repository-dispatch@v1 Notification Field Support for Workflow with repository-dispatch Oct 25, 2021
@8398a7 8398a7 added the help wanted Extra attention is needed label Nov 22, 2021
@bwmills
Copy link
Author

bwmills commented Apr 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants