Skip to content

Commit 09580f7

Browse files
[CI] Update Best Practices on Job Events for Stacked PRs (#149734)
I have seen a couple recent issues around workflows getting triggered on events that are not correctly configured to handle stacked PRs. This potentially resulted in workflows getting run twice (if they were also triggering on push events) or to not run at all (if there were branch restrictions for the pull_request event). Add some documentation to the best practices page so we can hopefully avoid these issues in the future and have some documentation to refer to during code review.
1 parent 1a0dd5a commit 09580f7

File tree

1 file changed

+28
-0
lines changed

1 file changed

+28
-0
lines changed

llvm/docs/CIBestPractices.rst

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -108,3 +108,31 @@ If specific jobs within the workflow need additional permissions, those
108108
permissions should be added within the specific job. This practice locks down
109109
all permissions by default and only enables them when needed, better enforcing
110110
the principle of least privilege.
111+
112+
Ensuring Workflows Run on the Correct Events
113+
--------------------------------------------
114+
115+
Github allows workflows to run on a multitude of events and it is important to
116+
configure a workflow such that it triggers on the correct events. There are
117+
two main best practices around events that trigger workflows:
118+
119+
1. Workflows that are designed to run on pull requests should not be
120+
restricted by target branch. Restricting the target branch unnecessarily
121+
will prevent any stacked PRs from being tested. ``pull_request`` events should
122+
not contain a branches key.
123+
124+
2. Workflows that are designed to also trigger on push events (e.g., for
125+
testing on ``main`` or one of the release branches) need to be restricted by
126+
branch. While pushes to a fork will not trigger a workflow run due to the
127+
``push`` event if the workflow already has its jobs disabled in forks
128+
(described above), stacked PRs will end up running jobs twice if the ``push``
129+
event does not have any branch restrictions. ``push`` events should have
130+
their branches restricted at the very least to ``main`` and the release
131+
branches as follows:
132+
133+
.. code-block:: yaml
134+
135+
push:
136+
branches:
137+
- main
138+
- releases/*

0 commit comments

Comments
 (0)