Migration is messy - request for better documentation and advice

Hey folks, I had the v1 setup for the slack action working beautifully with your block kit output:

      - name: Post to Slack Channel
        id: slack2
        uses: slackapi/[email protected]
        with:
          # https://app.slack.com/block-kit-builder
          channel-id: "some-amazing-channel"
          payload: |
            {
              "attachments": [
                {
                  "color": "#0080FF",
                  "blocks": [
                    {
                      "type": "section",
                      "text": {
                        "type": "mrkdwn",
                        "text": "*_${{ steps.get-service-name.outputs.SERVICE_NAME }}_ :factory: is doing a super special thing, checkout the url: <${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|build link>?"
                      }
                    }
                  ]
                }
              ]
            }
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
        continue-on-error: false

I don't see any examples similar to this. The channel was moved to the payload.. weird choice, but ok. Everything for block kit seems to be in yaml syntax? There's no way to use json I created previously? How would I migrate this?

This seems to mostly be in line but it dies fantastically without much of a helpful error: "A method must be decided"

      - name: Post to Slack Channel
        id: slack3
        uses: slackapi/[email protected]
        with:
          # https://app.slack.com/block-kit-builder
          payload: |
            channel: "some-amazing-channel"
            text: {
                "attachments": [
                  {
                    "color": "#0080FF",
                    "blocks": [
                      {
                        "type": "section",
                        "text": {
                          "type": "mrkdwn",
                          "text":  "*_${{ steps.get-service-name.outputs.SERVICE_NAME }}_ :factory: is doing a super special thing, checkout the url: <${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|build link>?"
                        }
                      }
                    ]
                  }
                ]
              }
          token: ${{ secrets.SLACK_BOT_TOKEN }}
        continue-on-error: false

Thanks for any help you can provide on how to migrate these.

@thejeff77

Hey @thejeff77 👋🏻 Thanks for planning to migrate to v2, we're happy to help you out!

Before diving too far, have you seen the v3.0.0 Release Changelog? I know it's not easy to find, but it includes quite a bit of detail on the changes, migrating from breaking changes, and examples.

@mwbrooks

Thanks @mwbrooks, I should have checked the release notes! A lot of projects just put these migration guides on the main README and the release notes are slim. But this migration guide is great, thanks again.

I found a couple things that I can change. Specifically:

"Recommended change: To continue replacing templated variables provided from the step env or default GitHub event context and payload, set the payload-templated variable to true."
I assume from the wording of this: "Payloads can now be written in YAML", that JSON is still supported, just no examples show json anymore?

In my opinion the templated payloads should default to true. May I inquire about the architectural choice behind defaulting to false?

@thejeff77

@thejeff77 Thanks for calling out that the README is a common place to reference migration guides! Let's use this issue to address this in a follow up 📚 ✨

In my opinion the templated payloads should default to true. May I inquire about the architectural choice behind defaulting to false?

Parsing templated variables by default has caused confusions of #226 which might've been cleared up in #347, but workflows using the method technique might make autogenerating a payload-file-path useful in certain workflows.

Defaulting to false makes it more clear that inputs aren't being changed unless specified, which we're hoping makes this action more predictable in these use cases 🙏

The actual variables used when templating a payload are also different than those of inline workflows which is a known limitation and can make this a confusion if unexpected replacements were to happen 👾

Recommended change: To continue replacing templated variables provided

I notice the examples you shared aren't using the payload-file-path option, so automatic variable replacement might happen for these inlined workflows! The payload-templated option can still be used, but might repeat some replacements.

JSON is still supported

This is true and something we'll improve documentation around. The entire payload must be either JSON or YAML, but both are supported. Most reference prefers YAML to match surrounding workflow syntax, but this example shows an "unwrapped" input JSON in a step!

These are all great thoughts and feedback you're sharing and I'm super open to discussing changes more, but also please let us know if other snags appear in the update 🚀

Thanks team for your extremely prompt, helpful, and thorough responses. I look forward to diving into this fully featured v2 action soon.

Navigation Menu

Repository navigation

Migration is messy - request for better documentation and advice #398

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Migration is messy - request for better documentation and advice #398

Description

Activity

mwbrooks commented on Feb 26, 2025

thejeff77 commented on Feb 27, 2025

zimeg commented on Feb 27, 2025

thejeff77 commented on Feb 27, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions