This updates the following third-party GitHub Actions to their latest versions.
- `actions/cache`
- `actions/checkout`
- `actions/upload-artifact`
- `actions/setup-node`
- `actions/setup-php`
- `actions/github-script`
See #57572.
git-svn-id: https://develop.svn.wordpress.org/trunk@55152 602fd350-edb4-49c9-b593-d223f7449a82
The `save-state` and `set-output` commands have been deprecated in GitHub Actions. This removes all occurrences of the command within workflow steps.
This will not remove all deprecated notices from workflow summaries (some third-party actions still contain instances of these commands and need to be fixed upstream), but it will fix the notices caused by custom workflow code.
See #56820.
git-svn-id: https://develop.svn.wordpress.org/trunk@54649 602fd350-edb4-49c9-b593-d223f7449a82
The latest version of the `actions/github-script` action fixes an issue where passing options to the action would remove any default values not passed (see https://github.com/actions/github-script/pull/293).
This also includes updates to other third-party actions, bringing all third-party versions in Core workflows to their latest versions:
- `actions/cache`
- `actions/setup-node`
- `codecov/codecov-action`
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54373 602fd350-edb4-49c9-b593-d223f7449a82
This was included in the original pull request that aimed to add support for `octokit/plugin-retry.js` in `actions/github-scripts`, but was actually removed before being merged.
Follow up to [54342].
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54343 602fd350-edb4-49c9-b593-d223f7449a82
This version adds support for `octokit/plugin-retry.js`, which retries requests automatically when `4xx` or `5xx` response codes are returned.
To start, the feature is configured to retry all `4xx` and `5xx` response codes, unless the server identifies as a teapot.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54342 602fd350-edb4-49c9-b593-d223f7449a82
There are several common reoccurring issues that sometimes cause GitHub Action workflows to fail (connection timeouts to WordPress.org or the Docker container registry, `npm install` failures, Chromium issues, etc.). Except when there are service level outages, most of these issues can be resolved by simply rerunning the workflow.
This introduces a new step within each of Core’s GitHub Action workflows that attempts to rerun the failed jobs within the workflow that encountered a failure if they are running for the first time. Since a workflow is not allowed to restart itself, a new `failed-workflow.yml` callable workflow is being introduced.
Other related adjustments in this changeset:
- The `actions/github-script` 3rd-party action is also now updated to the latest version (v6.2.0).
- A new secret, `GHA_WORKFLOW_DISPATCH`, has been introduced. This will replace the current one in use (`GHA_OLD_BRANCH_DISPATCH`) with a less specific name.
Props jorbin, desrosj.
Fixes#56407.
git-svn-id: https://develop.svn.wordpress.org/trunk@53947 602fd350-edb4-49c9-b593-d223f7449a82
When trying to determine the outcome of the previous run for a GitHub Action workflow, the current run is included in the list fetched from the GitHub API.
This adjusts the logic checking for the previous run to account for that and fixes notifications for the first workflow runs of a new branch or tag.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53735 602fd350-edb4-49c9-b593-d223f7449a82
The `workflow_run` event was added to restore Slack notifications for older branches (5.8 and older) without having to backport any changes while alternate approaches were explored.
The workflow has been tested and refined as a reusable one in `trunk`, and this approach is superior to the `workflow_run` event in several ways.
Primarily, the `workflow_run` event results in a separate workflow run being created for sending Slack notifications after the completion of each workflow triggered by `push`. When called as a reusable workflow, this does not happen and the additional jobs are instead added to the initial workflow. This makes which jobs are sending notifications for the current workflow more clear, and reduces the amount of noise (less workflow runs overall).
The `workflow_run` event also makes some data available in different ways than `push` events. By removing it, much of the logic within the workflow can be simplified.
See #56095.
git-svn-id: https://develop.svn.wordpress.org/trunk@53591 602fd350-edb4-49c9-b593-d223f7449a82
This updates the following GitHub Actions to the latest versions:
- `actions/checkout`
- `actions/cache`
- `actions/github-script`
- `actions/setup-node`
- `codecov/codecov-action`
- `shivammathur/setup-php`
- `slackapi/slack-github-action`
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53581 602fd350-edb4-49c9-b593-d223f7449a82
This adjusts the logic used to determine the outcome of the previous workflow run of the current one to account for `schedule` and `workflow_dispatch` events.
In the current state, only workflows triggered by `push` events are examined. This is causing failures when trying to post Slack notifications for the Test Coverage workflow, and inconsistent results for `workflow_dispatch` events when testing older branches on a schedule.
Follow up to [53466] and [53468].
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53534 602fd350-edb4-49c9-b593-d223f7449a82
This fixes the code added in [53466] to look at the correct workflow object when determining the outcome of the previous workflow run.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53468 602fd350-edb4-49c9-b593-d223f7449a82
When searching for previous workflow runs by branch, GitHub currently includes matches within forks.
If a contributor opens a pull request from their fork with a `head_ref` matching a Core branch that triggers a workflow on `push` event, the outcomes of the workflows associated with that pull request are currently used to determine if the previous workflow run had failed.
The result is a false “fixed” notifications when a commit immediately follows a failed workflow run from the pull request.
This adds a check to skip any workflow runs not triggered by a `push` event to prevent these inaccurate notifications.
Props SergeyBiryukov.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53466 602fd350-edb4-49c9-b593-d223f7449a82
This adjusts the workflow run URLs included in Slack notifications to link to the specific attempt being reported on making it easier for someone to see the proper context of a specific notification.
Additionally, this eliminates the need for a contributor to share the reason for a failure in Slack before restarting the workflow, as the link will always be to that specificattempt. When a “fixed” notification occurs for a subsequent run attempt, the link will be to the new, successful run attempt.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53427 602fd350-edb4-49c9-b593-d223f7449a82
This adjusts the logic of the Slack Notifications workflow to make the “fixed” notifications more reliable.
Currently, the workflow looks at the immediately preceding workflow run for the current branch. This fails to indicate that a workflow is fixed when other unrelated commits are made, and when rerunning the workflow after a false failure (timeout, etc.).
The workflow will now use the following logic to determine if something has been fixed:
- When a workflow is rerun, the conclusion for the immediately preceding run attempt will now be used to determine if the current attempt has “fixed” the workflow.
- When on the first run attempt for a workflow run, the workflow conclusion for the immediately preceding commit will be used.
- When on the first run attempt for a workflow run and no preceding commits for the current branch are present (this is a fresh tag or branch), always consider it “fixed”.
Props davidbaumwald.
See #54742.
git-svn-id: https://develop.svn.wordpress.org/trunk@53108 602fd350-edb4-49c9-b593-d223f7449a82
This fixes a JavaScript error in the Slack notifications workflow. This was causing the first workflow run for each workflow in a new branch or tag to be reported as a failure, even if the important parts of the workflow succeed.
When running a workflow for the first time, a default of `failure` is now used for the previous outcome. This will trigger a success notification to be sent to report successful branching/tagging.
Props davidbaumwald.
Fixes#54742.
git-svn-id: https://develop.svn.wordpress.org/trunk@53077 602fd350-edb4-49c9-b593-d223f7449a82
When using a workflow as a callable workflow, the job status check functions do not take the called workflow into account. This has caused some failures to be incorrectly reported as successful.
This adds an input to the Slack notifications workflow for when the `workflow_call` event is used.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@52002 602fd350-edb4-49c9-b593-d223f7449a82
This makes the needed adjustments to fix Slack notifications for `scheduled` and `workflow_dispatch` events. The data needed to send notifications for these events are stored in different locations, or need to be accessed through API requests.
Follow up to [51921], [51937].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51953 602fd350-edb4-49c9-b593-d223f7449a82
When a workflow is triggered through a `workflow_run` event, the context is not the original workflow. The details about the original workflow are passed through the `github.event` context.
This also moves the conditional check controlling whether the Slack workflow is run into the calling workflows to prevent them from running for pull requests.
Follow up to [51921-51922,51924-51925,51934].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51937 602fd350-edb4-49c9-b593-d223f7449a82
In [51921], the GitHub Actions workflows were updated to utilize the Slack notifications workflow as a callable one instead of on the `workflow_run` event.
This eliminated the need for an additional “Slack Notifications” workflow run for every completed workflow, but only when other workflows are updated as well. This resulted in notifications from older branches breaking, as the changes in [51921] were not backported.
Instead of backporting the needed changes now (the Slack workflow is still being polished), this commit partially restores the `workflow_run` event for older branches so that notifications will resume.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51934 602fd350-edb4-49c9-b593-d223f7449a82
Secrets are not available within callable workflows by default. They must be defined within the callable workflow, and passed from the calling workflow.
Follow up to [51921-51922].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51924 602fd350-edb4-49c9-b593-d223f7449a82
The ability to reuse workflow files within GitHub Action workflows was recently added and allows for less code duplication.
In the context of WordPress Core, this also eliminates the need for an additional “Slack Notifications” workflow to run for every completed workflow.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51921 602fd350-edb4-49c9-b593-d223f7449a82
This gives more context to GitHub Action related Slack messages without the need to click the workflow URL, or unfurl the links (which shows lots of unnecessary information, such as the repository description and image).
Props earnjam.
See #52644.
git-svn-id: https://develop.svn.wordpress.org/trunk@51647 602fd350-edb4-49c9-b593-d223f7449a82
Since branch filtering happens prior to the workflow run being created, filtering the branches that `workflow_run` will fire on for this workflow should cut down on the number of skipped “Slack Notifications” runs listed in the Actions section of the repository.
This also removes the check for a `skipped` outcome in the requesting workflow. Workflows for push events resulting from WordPress Core commits are never skipped.
See #52644.
git-svn-id: https://develop.svn.wordpress.org/trunk@51558 602fd350-edb4-49c9-b593-d223f7449a82
This updates the conditional check for the Slack notifications workflow to check the event of the original workflow and not the one requested through the `workflow_run:completed` event.
The run triggering the event is accessible at `github.event.workflow_run`.
Props Clorith.
See #52644.
git-svn-id: https://develop.svn.wordpress.org/trunk@51555 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@51535 602fd350-edb4-49c9-b593-d223f7449a82
