From 89d59a36016f85f63afd3dfd15effdcb3d2a8421 Mon Sep 17 00:00:00 2001 From: Joey Parrish Date: Fri, 17 Jan 2025 14:18:54 -0800 Subject: [PATCH] ci: Update comments for the settings workflow (#1476) Since the introduction of `vars` to GitHub Actions, I started using that instead of the "environments" trick I used in Packager. However, it has become clear now that the `vars` strategy has major drawbacks, such as requiring the use of `pull_request_target`, which should only be used for actions that do not execute PR-author-controlled code. This updates the comments to clarify why this is used. This reusable settings workflow will also be deployed now in other repos to standardize on this "environments" mechanism, which is safer than `vars`. --- .github/workflows/settings.yaml | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/.github/workflows/settings.yaml b/.github/workflows/settings.yaml index 14317ea8ff..9cc35bf7d1 100644 --- a/.github/workflows/settings.yaml +++ b/.github/workflows/settings.yaml @@ -6,9 +6,15 @@ # A reusable workflow to extract settings from a repository. # To enable a setting, create a "GitHub Environment" with the same name. -# This is a hack to enable per-repo settings that aren't copied to a fork. -# Without this, test workflows for a fork would time out waiting for -# self-hosted runners that the fork doesn't have. +# +# This enables per-repo settings that aren't copied to a fork. This is better +# than "vars" or "secrets", since those would require the use of +# `pull_request_target` instead of `pull_request` triggers, which come with +# additional risks such as the bypassing of "require approval" rules for +# workflows. +# +# Without a setting for flags like "self_hosted", test workflows for a fork +# would time out waiting for self-hosted runners that the fork doesn't have. name: Settings # Runs when called from another workflow.