GoogleCloudPlatform / samples-style-guide

Guidelines on writing effective Google Cloud samples.
https://googlecloudplatform.github.io/samples-style-guide/
Apache License 2.0
11 stars 19 forks source link

Site: Deploy Previews from forks #106

Open grayside opened 1 year ago

grayside commented 1 year ago

Background

This repository's source code is used with the hugo static site generator to build and deploy a website to GitHub Pages. We have a preview system that writes a complete site build to a subdirectory namespaced to the Pull Request to facilitate reviews. This preview system makes reviews much easier.

Problem

The preview system for the style guide is currently locked to changes pushed directly to the repository, no changes from forks:

https://github.com/GoogleCloudPlatform/samples-style-guide/blob/0bb1c7e9d98bd5e5de36374c012fc97b5418421a/.github/workflows/github_pages_preview.yml#L72

However, there can be significant contributions from folks working in a fork, such as #101.

The reason this is locked down is that providing write access to a fork is a pretty bad security risk.

Proposal

Learning from On pull_request_target, labels, and working with insecurity., @glasnt proposes using labels to toggle permission to run a workflow to test and label. I propose an even more restricted approach to allow the existing PR preview system to preview fork changes.

  1. If the changes touches the .github directory, cancel. We only expect repository collaborators to make changes to the preview tooling, and this reduces the risk of reviewer error.
  2. Only deploy from fork if a preview: generate label is applied by a maintainer
  3. When the preview workflow is run, automatically remove the label (optionally, add status labels like preview: failed or preview: ready)

As a further race condition measure:

  1. If we can't check out the branch at the commit associated with the label, can we compare the latest commit on the branch to the commit or parent commit of the checkout?

Initial Security Assessment

averikitsch commented 1 year ago

This proposal cover my security concerns. We may wish to explore deployment environments (https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment). Environments can require approval before moving on to a deployment workflow step.