Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Website previews for fork PRs need a workflow_run deployment on a trusted branch

Aberta
  • Algo errado?
#890 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github-actions, typescript
Domínio
ci-cd

Direção de pesquisa

Start by reading deploy-website-preview.yml and the related constraints in #888 and #889. Resolve the artifact-lifetime, PR-commenting, and fork-preview questions before choosing the pull_request/workflow_run design. Done means a safe, documented decision and a preview path that never executes fork code with deployment secrets.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

A pull_request run from a fork receives no repository secrets — GitHub withholds them from code the PR author controls, regardless of the permissions: block or the environment configuration. So deploy-website-preview.yml cannot deploy a preview for a fork PR at all, and #888 makes it skip with a notice rather than fail at wrangler deploy.

That leaves fork contributors — the more likely contributor in an open-source relay — with no preview, which is exactly the case a site change most needs one for.

What it needs

The standard shape is a two-workflow split:

  1. pull_request (unprivileged) builds the site, uploads the built tree as an artifact, and writes nothing else.
  2. workflow_run on a trusted branch reads that artifact and deploys it with the secrets available to main.

The security-critical property is that the deploying job never executes fork code: it unpacks a static build, which is data, rather than checking out and running the PR's package.json, build scripts or wrangler config. Even then, the deployed content is attacker-controlled — which is precisely why previews must stay on their own domain and out of the production one (#889 enforces that host boundary in the router).

Open questions worth settling before building it

  • does the artifact path survive PR deletion between the two runs
  • how to comment on the PR from a workflow_run context, which has no pull_request payload (the run's associated_pull_requests is the route, and it can be empty)
  • whether a preview worker should be created for a fork at all, or the build published as an artifact link only

Found while fixing review findings on #888; not attempted there, because improvising a privileged deploy path inside a bug fix is how a supply-chain hole gets shipped.

Linguagem predominante
TypeScript
Estrelas
829
Forks
234
Merge médio
18h 43min
PRs com merge (30d)
67

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cameri/nostream

Todas as issues de cameri/nostream

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.