In our project , we're trying to achieve the desired effect (triggering one workflow from another workflow) by creating the deployment using a personal access token, not the GITHUB_TOKEN provided by the environment . The deployment is created as expected, and the GitHub UI confirms that our bot account was responsible, e.g. wpt-preview-20350 — f477bd9b Deployed 31 minutes ago by wpt-pr-bot But still, our workflow configured with "on: deployment"  is never executed. Can anyone at GitHub explain why this is the case?  https://github.com/web-platform-tests/wpt  https://github.com/web-platform-tests/wpt/blob/e38cfc949a8c8d1709e60ff8d5b44a0f9aedea98/.github/workflows/pull_request_previews.yml#L21-L29  https://github.com/web-platform-tests/wpt/blob/e38cfc949a8c8d1709e60ff8d5b44a0f9aedea98/.github/workflows/detect_pull_request_preview.yml#L2
... View more
GitHub Actions are documented to recognize the exit code 78 as neither passing nor failing: When an action returns this exit status, GitHub terminates all concurrently running actions and prevents any future actions from starting. The associated check run shows a `neutral` status, and the overall check suite will have a status of `success` as long as there were no failed or cancelled actions. - GitHub Actions - Accessing the runtime environment In practice, when a process exits with that code, GitHub reports the Action and containing Workflow as "failed." The logs end with the following line: ##[error]Docker run failed with exit code 78 Here is a recent example of this. This was working as expected until my project migrated to the latest beta version of GitHub Actions, so this may be a regression in that release.
... View more