Bump slackapi/slack-github-action from 3.0.3 to 4.0.0

[dependabot]

Bumps slackapi/slack-github-action from 3.0.3 to 4.0.0.

Release notes

Sourced from slackapi/slack-github-action's releases.

Slack GitHub Action v4.0.0

Major Changes

• b1974f0: build: parse yaml with more strict multiline indentation rules

  Internal dependencies of js-yaml@v5 make YAML parsing more strict and compliant with the YAML specification. Indentation is now required for values that span multiple lines against the base value.

  See the YAML line prefixes spec for the expected indentation rule:

    channel: "C0123"
    text: "first line
  
  second line"
  
  
  second line"

Patch Changes

• 654bb72: chore: provide global fetch proxied configurations with updates to web api and webhook packages

Slack GitHub Action v3.0.5

Patch Changes

• 96fddbe: fix: revert multiline yaml parsing indentation change

Slack GitHub Action v3.0.4

Patch Changes

• fa03fe4: refactor: send webhooks with the @slack/webhook package

Changelog

Sourced from slackapi/slack-github-action's changelog.

4.0.0

Major Changes

• b1974f0: build: parse yaml with more strict multiline indentation rules

  Internal dependencies of js-yaml@v5 make YAML parsing more strict and compliant with the YAML specification. Indentation is now required for values that span multiple lines against the base value.

  See the YAML line prefixes spec for the expected indentation rule:

    channel: "C0123"
    text: "first line
  
  second line"
  
  
  second line"

Patch Changes

• 654bb72: chore: provide global fetch proxied configurations with updates to web api and webhook packages

3.0.5

Patch Changes

• 96fddbe: fix: revert multiline yaml parsing indentation change

3.0.4

Patch Changes

• fa03fe4: refactor: send webhooks with the @slack/webhook package

Commits

• dcb1066 chore: release
• 53861e0 chore: release (#645)
• b1974f0 build!: parse yaml with more strict multiline indentation rules (#640)
• 947ed06 build(deps): bump undici from 7.28.0 to 8.7.0 (#653)
• 03922a9 chore: track undici-types to the resolved undici version (#652)
• 31d473e build(deps-dev): bump typescript from 6.0.3 to 7.0.2 (#651)
• 3ca6997 build(deps-dev): bump sinon and @​types/sinon (#649)
• 26a5ad3 build(deps): bump actions/setup-node from 6.4.0 to 7.0.0 (#647)
• 5092efb build(deps-dev): bump @​biomejs/biome from 2.5.3 to 2.5.4 (#650)
• 3548c3e build(deps): bump slackapi/slack-github-action from 3.0.3 to 3.0.5 (#646)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[rtibblesbot]

🔵 Review posted

Last updated: 2026-08-01 00:52 UTC

[rtibblesbot]

PR #91 — slackapi/slack-github-action 3.0.3 → 4.0.0 (major), CI action used by production workflows. All 7 occurrences updated; no code changes required.

CI: passing — but it carries no signal here. Every check on this PR is one of the repo's own community workflows reacting to the PR event; none of the five changed workflows runs, and their Slack steps are gated behind runtime if: conditions anyway.

Breaking changes: one — b1974f0 (#640), a js-yaml 4.2.0 → 5.2.1 bump that requires indentation for values spanning multiple lines. The upstream test diff scopes it precisely: it only affects block-style YAML with multi-line quoted scalars (text: "first line\n\n second line"). Every payload here is a JSON flow mapping with single-line scalars, and multi-line flow collections are unaffected. src/content.js also falls back to JSON.parse() when load() throws, so well-formed JSON parses regardless. Note the history: 3.0.4 shipped this change, 3.0.5 reverted it (#638), v4.0.0 reintroduces it as a major.

Checked that no interpolated step output can inject a raw newline at runtime — the only way these payloads could become multi-line. All are single-line template literals, except pr-statistics.yml, whose slack_message does contain newlines but is wrapped in toJSON(...) (line 47), emitting a single-line escaped string. That wrapping is the right call and makes the repo's largest, most escape-heavy payload immune to the parsing change.

Behavioral change worth knowing: #630 (shipped in 3.0.4) moved webhook delivery to the @slack/webhook package instead of a hand-rolled request. All seven call sites use webhook-type: incoming-webhook, so this is the change most likely to alter runtime behaviour. Upstream labelled it patch with no documented behaviour change.

Not applicable: #619 (@slack/web-api v8 + proxied fetch) — this repo sets no proxy or method input.

Security fixes: none in the action. Transitively, js-yaml 5.2.1 removes quadratic complexity in !!omap and adds loader alias/merge-key limits; not reachable from these payloads.

Peer/runtime changes: none — action.yml declares runs: using: "node24" at both versions.

suggestion: if you want empirical confirmation, pr-statistics.yml has a workflow_dispatch path — trigger it once post-merge and confirm the Slack message lands. The failure mode otherwise is silent: a SlackError surfacing days later when a contributor comments or the weekly cron fires.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status