shylie/llvm-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[CI] Update Best Practices on Job Events for Stacked PRs (#149734)

Browse Source 
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.
This commit is contained in:
Aiden Grossman 2025-07-21 07:13:58 -07:00 committed by GitHub
parent 1a0dd5a67e
commit 09580f73c2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 28 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
llvm/docs/CIBestPractices.rst
View File

@ -108,3 +108,31 @@ If specific jobs within the workflow need additional permissions, those
permissions should be added within the specific job. This practice locks down permissions should be added within the specific job. This practice locks down
all permissions by default and only enables them when needed, better enforcing all permissions by default and only enables them when needed, better enforcing
the principle of least privilege. the principle of least privilege.
Ensuring Workflows Run on the Correct Events
--------------------------------------------
Github allows workflows to run on a multitude of events and it is important to
configure a workflow such that it triggers on the correct events. There are
two main best practices around events that trigger workflows:
1. Workflows that are designed to run on pull requests should not be
restricted by target branch. Restricting the target branch unnecessarily
will prevent any stacked PRs from being tested. ``pull_request`` events should
not contain a branches key.
2. Workflows that are designed to also trigger on push events (e.g., for
testing on ``main`` or one of the release branches) need to be restricted by
branch. While pushes to a fork will not trigger a workflow run due to the
``push`` event if the workflow already has its jobs disabled in forks
(described above), stacked PRs will end up running jobs twice if the ``push``
event does not have any branch restrictions. ``push`` events should have
their branches restricted at the very least to ``main`` and the release
branches as follows:
.. code-block:: yaml
push:
branches:
- main
- releases/*