Execute build and e2e tests on push, not pr. #1794
Conversation
There was a problem hiding this comment.
The issue with this PR is we require all of the status checks to pass via our main ruleset, but Github (annoyingly) does not have a notion of separate status checks for PRs and the merge queue. I am totally on board with this separation of jobs, to be clear.
My understanding is the workaround for this is "running" the action, but have them be no-ops that "pass" automatically in the context you do not want them to run. I believe the discussion I linked in chat does it via conditionals on the event type, though I have seen others in the past that do it via declaring separate, identically named jobs.
One other point, if we are skipping certain jobs for PRs, can we add the workflow_dispatch event type to the trigger list for the skipped jobs? This should allow us to manually start action runs, which I imagine we will want for debugging eventual failures without needing to enqueue every time.
3405691582
force-pushed
the
workflow
branch
2 times, most recently
from
834faf1 to
d033ad7
Compare
As configured, the same set of tests runs on pull request and on the merge queue. This is redundant, and flakes can cause large delays. Ideally, we should reduce the redundancy, either by pushing tests from pull request to merge, or vice versa. The consensus is on the former, to ensure that the code at HEAD is most likely to be passing tests. As I understand it, the `push` GitHub workflow event triggers on the merge queue, so the new pull request workflow triggers on the `pull_request` event. This workflow does not run any of the build or end-to-end checks, which can take a long time, only the static and unit checks.
I'm not sure I understand this point. Can you elaborate? Adding |
2 participants
As configured, the same set of tests runs on pull request and on the merge queue. This is redundant, and flakes can cause large delays. Ideally, we should reduce the redundancy, either by pushing tests from pull request to merge, or vice versa. The consensus is on the former, to ensure that the code at HEAD is most likely to be passing tests.
As I understand it, the
pushGitHub workflow event triggers on the merge queue, so the new pull request workflow triggers on thepull_requestevent. This workflow does not run any of the build or end-to-end checks, which can take a long time, only the static and unit checks.