Our study of the most popular GitHub Actions for sending basic Slack notifications.

If you rely on GitHub Actions to automate your tests, builds, or anything else, your final step might send a notification to Slack to report on the status of the workflow.

There are many GitHub Actions available in the marketplace that you can drop into your YAML files to fire off a Slack notification. But some still use older versions of Slack APIs that may be dropped. Others allow full flexibility to format messages according to Slack’s APIs - but if all you want is to report on your workflow status you might prefer that the action assembles a suitable message from the workflow data by itself.

So we tried out the most popular actions to find out which one you should use today!

What to consider

All actions require you to connect to Slack somehow, and usually store a token of some sort in the GitHub repo secrets. There are multiple, old and new, ways to do that so we’ll also explain the different ways that Slack authentication can work, and which is the best approach for an action.

On the GitHub Actions side, unless you’re actually using actions to send bespoke messages to delight your Slack colleagues, your main aim will be to monitor your workflow statuses. So which actions take the time to understand the status of your current workflow and provide easy ways to piece together notifications without you having to carefully structure your own messages?

Note - we built Endid as a Slack app to intelligently monitor all repo workflows automatically without any configuration. Of course we think that’s the best way to keep track of your workflows, but this article only considers actions that you need to insert at the end of each YAML file.

Most of the actions explain that you need to use if: always() on a step to ensure the notification step is run even following failure of the earlier workflow steps. If you have multiple jobs, keeping track of the overall status becomes quite complicated to get right, as I’ve written about before.

Slack Authentication

There are four different Slack authentication methods that actions might use:

1. Register your own Slack app for a Bot Token
2. Register your own Slack app for an Incoming Webhook URL
3. Install Slack’s generic Incoming Webhook app and view the URL
4. Create a ‘no-code’ Workflow Builder workflow and generate a webhook URL

The modern methods

The first two of these are probably the safest routes today. Registering your own Slack app is not as complicated as it sounds - it’s a case of a few clicks for an admin of your Slack workspace. An app can become as complex as one of the publicly available apps in the Slack App Directory, but in your case you only really need to use it as a means to authenticate a ‘bot’ into your own workspace.

There isn’t too much difference between the first two options for sending a simple message. The Bot Token approach is more flexible - you can update existing messages, for example. The webhook method prompts the admin to select a single channel when they authenticate, whereas the bot token can more easily write to multiple channels without reauthenticating in the future.

So, for flexibility, I recommend using the bot token approach. You might consider the webhook style of authentication if the admin wants more control over users’ ability to post to many channels just by changing the GitHub Actions YAML.

On the other hand, if you decide a particular action suits your needs, that action might only support one approach and thus dictate your Slack authentication choice.

The other ways

Some older actions still ask you to install a generic Incoming Webhook app (provided by Slack) instead of registering your own, but this is now marked as a legacy method.

Workflow Builder is a new (paid plan only) no-code tool provided by Slack, allowing organisations to piece together their own workflows that can, for example, pop up a form in Slack and then pipe that data into various supported components, such as a Google Sheet or a CRM tool.

Slack has actually contributed its own action into the GitHub marketplace and that recommends that you use Workflow Builder for auth (while also supporting the other non-legacy approaches). However, I would take that with a large pinch of salt and assume they are primarily keen to generate excitement for their new Workflow Builder offering. In practice, it is harder to set up and only gives any advantage if you do actually want to initiate a Slack workflow based on data provided from your GitHub Actions workflow. For a simple notification, it is not necessary to use this - and it’s not available anyway for free Slack workspaces.

Understanding of GitHub Actions

Some actions, such as Slack’s own action, generally require you to address Slack’s API verbatim - that is, construct a JSON object including the blocks that will spell out a formatted message containing all relevant workflow information from GitHub. That’s a lot for you to piece together, especially if maintaining across many YAML files, and might need an understanding of Slack’s API.

Our overall prefered action, action-slack allows a simple comma-separated list of fields that you can display in Slack.

For a GitHub action step like this:

steps:
  - uses: "8398a7/action-slack@v3"
    with:
      status: ${{ job.status }}
      fields: "repo,message,commit,author,action,eventName,ref,workflow,job,took,pullRequest"
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
    if: always() # Pick up events even if the job fails or is canceled.

This appears in Slack:

You can cut out any of these data by editing the fields input to the action - the default is just repo,message.

Our Recommendation

The action-slack action appears to fit our criteria better than most actions on the front page of the GitHub Actions Marketplace when searching for the term “Slack”.

While the documentation is well-structured in the end, it doesn’t actually explain the steps for creating your own Slack App in the first place!

Furthermore, most actions that we tried out use an old ‘attachments’ messaging format (the green bar along the left is the give-away) which might have their “visibility or utility reduced” in the future. Those that don’t - that use the newer ‘Block Kit’ message formats - are all the ones that require you to construct your own messages from scratch, requiring a minor understanding of the Slack API.

We have also been unable to find an action that displays the commit message clearly - at Endid we took a lot of care translating the GitHub markdown into Slack markdown so links appear as clickable rather than as raw markdown, while also truncating the message safely.

All the actions are provided free-of-charge so it is important that we express some gratitude for their existence… but it is also worth understanding that they all have their different strengths and weaknesses in the long history of Slack messaging API changes!

There are many other Slack actions in the long tail of the marketplace - maybe it’s time for one of the newer but less used actions to surface to the top?