Make WordPress Core

Opened 5 months ago

Last modified 7 hours ago

#52644 new task (blessed)

Configure Slack notifications for GitHub Action workflows

Reported by: desrosj Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.6
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:


Follow up to #50401.

TravisCI used to report changes in build status to Slack in the #core channel.

The following would be reported:

  • Every build that failed.
  • The first passing build in a branch after a failed build.

Some additional ideas for expanding this:

  • Posting every build result to the #core-firehose, or a new #core-ci-firehose

@helen had created GH-808 to explore setting this up.

Attachments (1)

Screen Shot 2021-08-04 at 3.16.05 pm.png (144.6 KB) - added by peterwilsoncc 22 hours ago.

Download all attachments as: .zip

Change History (15)

This ticket was mentioned in Slack in #core by chaion07. View the logs.

2 months ago

#2 @peterwilsoncc
2 months ago

Hi @desrosj,

This was discussed in a 5.8 bug scrubbing session today.

As this doesn't touch production files, it was left on the milestone but feel free to change the milestone if you don't have bandwidth for this release cycle.

Thanks for your contributions to WordPress!

#3 @desrosj
7 weeks ago

  • Milestone changed from 5.8 to 5.9

I'm going to punt this to 5.9 as I won't have the time to address this in the weeks leading up to 5.8.

This ticket was mentioned in PR #1529 on WordPress/wordpress-develop by desrosj.

6 days ago

  • Keywords has-patch added

#5 @desrosj
6 days ago

In 51511:

Build/Test Tools: Post a message to #core in Slack when a workflow fails.

This adds an additional step to each GitHub Action workflow file that posts a message to #core in Slack every time a workflow run fails.

A minor test and spacing change is included in this commit in order to that messages are posted correctly and will be reverted after testing.

See #52644.

#6 @desrosj
6 days ago

In 51512:

Build/Test Tools: Revert the test and coding standards changes in [51511].

These were temporary for testing Slack messages when GitHub Action workflows fail.

See #52644.

#7 follow-up: @desrosj
6 days ago

Looks like [51511] is doing the trick!

Some notes:

  • This will post every non-pull request workflow failure to #core.
  • Unfortunately, because this requires the job to actually run, a notification will not be posted if the job times out or fails due to a failure at the service level, such as a GitHub Action outage, or a runner that hangs and times out.
  • In Travis, there was a setting to post the first successful job following a failure to Slack. There is no straightforward way to accomplish this in GHA. It could be accomplished with a combination of REST API calls, but haven't figured out the best way for this yet.
  • We could also post all workflow results regardless of outcome to the #core-firehose.
  • We could also create a #core-ci channel that also receives a post for all workflow results regardless of outcome.
  • This will need to be backported to all branches so that Slack notifications are posted when old branches have failed workflow runs.

This ticket was mentioned in PR #1539 on WordPress/wordpress-develop by desrosj.

2 days ago

Trac ticket:

#9 @desrosj
38 hours ago

In 51535:

Build/Test Tools: Expand Slack notifications for GitHub Actions.

This expands Slack notifications to include success, cancelled, and “fixed” GitHub Action workflow run outcomes in addition to failures.

A “fixed” outcome occurs when the previous run for a workflow failed and the current one succeeds. This matches the behavior that was native to TravisCI by setting on_success for notifications to change.

The message details and where each outcome is posted is controlled by Slack workflows.

The Slack notification logic has also been pulled into a separate workflow to prevent repeating code in every workflow.

See #52644.

#10 @desrosj
37 hours ago

In 51536:

Build/Test Tools: Correct invalid JSON in Slack payload.

The outer marks are not required and produce invalid JSON.

See #52644.

#11 @desrosj
37 hours ago

In 51537:

Build/Test Tools: Revert changes only included for testing purposes.

Follow up to [51535-51536].

See #52644.

#12 in reply to: ↑ 7 @desrosj
35 hours ago

Some revised notes after [51535-51537]:

  • Slack notifications are now controlled by a separate workflow that runs on the workflow_run event when a listed workflow is completed. I took this route to prevent repeating large amounts of code across all workflows where Slack notifications are desired. But ideally, this workflow would be published as an action that could be defined in the uses: for a step.
  • The first successful job following a failure will now be posted as a "fixed" notice to #core. There are some potential edge cases with the current implementation where re-running workflows could result in the wrong workflow run being used for comparison.
  • All workflow results regardless of outcome are posted to to the #core-firehose.
  • All workflow results regardless of outcome are posted to the new #core-ci-firehose channel.
  • Since these notifications are controlled in a separate workflow initiated on the workflow_run event, this does not technically need to be backported (all workflow_run events are created against the primary branch). But, [51511-51512,51535-51537] could be backported just to have consistent contents of the .github/workflows directory.
  • The messages themselves are configured within Slack Workflows.

I'm going to leave this open in case any adjustments are needed.

#13 @peterwilsoncc
22 hours ago

Cool screenshot, peterwilsoncc.

Everyone else can ignore it as I've found the setting in Slack to prevent actions expanding -- and used web developer tools to read the truncated tex

This ticket was mentioned in Slack in #core by sergey. View the logs.

7 hours ago

Note: See TracTickets for help on using tickets.