From 1a8d06089e77397cf6975a6b29decb9a5d513528 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 4 Jan 2022 13:01:27 -0500 Subject: [PATCH] use pull_request for the private staging-build-and-deploy (#23783) --- .../workflows/staging-build-and-deploy-pr.yml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/.github/workflows/staging-build-and-deploy-pr.yml b/.github/workflows/staging-build-and-deploy-pr.yml index 69cb8195e6..d0d20ae68c 100644 --- a/.github/workflows/staging-build-and-deploy-pr.yml +++ b/.github/workflows/staging-build-and-deploy-pr.yml @@ -6,16 +6,16 @@ name: Staging - Build and Deploy PR (fast and private-only) # This whole workflow is only guaranteed to be secure in the *private # repo* and because we repo-sync these files over the to the public one, -# IT'S CRUCIALLY IMPORTANT THAT THIS WORKFLOW IS ONLY ENABLED IN docs-internal! +# IT'S IMPORTANT THAT THIS WORKFLOW IS ONLY ENABLED IN docs-internal! on: - # Ideally, we'd like to use 'pull_request' because we can more easily - # test changes to this workflow without relying on merges to 'main'. - # But this is guaranteed to be safer and won't have the problem of - # necessary secrets not being available. - # Perhaps some day when we're confident this workflow will always - # work in a regular PR, we can switch to that. - pull_request_target: + # The advantage of 'pull_request' over 'pull_request_target' is that we + # can make changes to this file and test them in a pull request, instead + # of relying on landing it in 'main' first. + # From a security point of view, its arguably safer this way because + # unlike 'pull_request_target', these only have secrets if the pull + # request creator has permission to access secrets. + pull_request: permissions: actions: read