YAML! And more API methods! With improved erroring! And more!

Sending data to Slack can now be done with the YAML format, and that data can be sent to [a Slack API method][methods] or technique of choice with the provided payload. And additional configurations can improve error handling or customize values between steps.

Breaking changes happen with this update and recommended migration strategies are detailed below. Adding this step to new workflows might prefer to follow the README instead 📚

What's changed

Both inputs of payload variables, techniques for sending the payload, additional configurations, and expected outputs were changed:

• Sending variables
  • Breaking changes
    • Only one payload input can be provided
    • Only one technique to send can be provided
    • Variable replacements no longer happen by default
    • Payload file path parsed option was removed
  • Enhancements
    • Payloads can now be written in YAML
    • Payload can now be written in unwrapped JSON
• Sending techniques
  • Technique 1: Slack Workflow Builder
    • Breaking changes
      • The webhook type must be specified in webhook inputs
      • Payload flattening no longer happens by default
    • Enhancements
      • The webhook URL can be specified in webhook inputs
  • Technique 2: Slack API method
    • Breaking changes
      • The Slack API method now must be specified in inputs
      • A token must be provided with other inputs
      • Inputs to the Slack API method must be provided in payloads
      • Messages cannot be sent to multiple channels in one step
  • Technique 3: Slack incoming webhook
    • Breaking changes
      • The webhook type must be specified for incoming webhooks
    • Enhancements
      • The webhook URL can be specified for incoming webhook
• Additional configurations
  • Enhancements
    • Steps can exit with an error after a failed Slack API call
    • Failed requests can be retried various amounts of times
    • Provided payloads can be flattened with a delimiter
    • Provided payloads can have templated variables replaced
    • Proxying HTTPS requests can be done within inputs
• Expected outputs
  • Breaking changes
    • The time value is now returned as the Unix epoch time
  • Enhancements
    • An ok value is added to represent response success
    • A response value is added with the response data

The following sections detail these changes with recommended changes for existing GitHub workflows using this step and certain features.

If something seems off after making these changes, please feel free to [open an issue][issues] for discussion! 👾

Sending variables

The source of variables remains the same, using one of the following inputs:

• payload: Inputs written inline in your GitHub workflow file.
• payload-file-path: Inputs gathered from a file.
• No input: Uses the default event [context][event-context] with a [payload][event-payload] matching the GitHub event.

⚠️ Breaking changes

Only one payload input can be provided

This Action now exits with an error if both payload and payload-file-path are provided.

Prior to updating: Both options could be provided with payload being preferred.

Recommended change: Use either payload, payload-file-path, or neither, when providing inputs. But don't include both.

Only one technique to send can be provided

This Action now exits with an error if both method and webhook techniques are provided.

Prior to updating: Both techniques could be used to send the same payload.

Recommended change: Use either method or webhook to send data, but not both.

Variable replacements no longer happen by default

This Action now sends payload provided in a payload-file-path file exactly as is.

Prior to updating: Templatized variables in input files were replaced with the matching github or env variable:

{
  "channel": "${{ env.SLACK_CHANNEL_ID }}",
  "text": "A commit was made: ${{ github.sha }}"
}

Changing the above file into something like this before being sent:

{
  "channel": "C0123456789",
  "text": "A commit was made: 3982e204d2ae590e908dd1e279e63933da566c8c"
}

Recommended change: To continue replacing templated variables provided from the step env or default GitHub event [context][event-context] and [payload][event-payload], set the payload-templated variable to true.

Payload file path parsed option was removed

This Action removed the payload-file-path-parsed input option.

Prior to updating: This option, which defaulted to true, could be set to false to avoid replacing templatized variables in a provided payload-file-path file.

Recommended change: Remove this option if it's set to false or set the new payload-templated option to true to continue parsing the provided payload.

🎁 Enhancements

Payloads can now be written in YAML

This Action now supports writing payload or payload-file-path values with YAML!

Prior to updating: Values provided as payloads had to be JSON.

Recommended change: Optional. Format the input payload value as YAML to match the surrounding steps:

- name: Post to a Slack channel
  uses: slackapi/slack-github-action@v2.0.0
  with:
    method: chat.postMessage
    token: ${{ secrets.SLACK_BOT_TOKEN }}
    payload: |
      channel: ${{ secrets.SLACK_CHANNEL_ID }}
      text: "Greetings <@channel>!"

Payload can now be written in unwrapped JSON

This Action now supports writing payload with unwrapped JSON, where surrounding braces are removed.

Prior to updating: Values provided as payloads had to be JSON.

Recommended change: Optional. Remove the surrounding braces from an existing payload value:

- name: Post to a Slack channel
  uses: slackapi/slack-github-action@v2.0.0
  with:
    method: chat.postMessage
    token: ${{ secrets.SLACK_BOT_TOKEN }}
    payload: |
      "channel": "${{ secrets.SLACK_CHANNEL_ID }}",
      "text": "Greetings <@channel>!",

Sending techniques

The techniques for sending variables remains the same, using one of the following:

• Technique 1: [Slack Workflow Builder][wfb]
• Technique 2: [Slack API method][methods]
• Technique 3: [Slack incoming webhook][incoming-webhook]

Changes for different technique might be different and are included in each of the following sections.

Technique 1: Slack Workflow Builder

⚠️ Breaking changes

The webhook type must be specified in webhook inputs

This Action now requires setting the webhook-type as a step input value.

Prior to updating: The webhook type could be omitted to send to Workflow Builder.

Recommended change: Set the webhook-type value to webhook-trigger, as shown in the example below.

Payload flattening no longer happens by default

This Action no longer flattens or stringifies payloads being sent to Workflow Builder by default.

Prior to updating: Payloads sent using a webhook trigger were flattened with a . delimiter and have values stringified before being sent.

Recommended change: If payload flattening is needed, use the payload-delimiter option. Inputs of Slack workflows should use an underscore _ as a delimiter to match expected inputs of Workflow Builder:

- name: Send GitHub Action data to a Slack workflow
  uses: slackapi/slack-github-action@v2.0.0
  with:
    payload-delimiter: "_"
    webhook: ${{ secrets.SLACK_WEBHOOK_URL }}
    webhook-type: webhook-trigger

🎁 Enhancements

The webhook URL can be specified in webhook inputs

This Action can now set the webhook URL as a step input.

Prior to updating: The SLACK_WEBHOOK_URL environm...