Separate ordinary PR tests and docs builds from privileged publishing

Aperta
  • Qualcosa non va?
#458 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, python
Ambito
ci-cd, devops

Direzione di ricerca

Start by reading .github/workflows/test_and_docs.yml and .github/workflows/module_tests.yml, then trace their callers, required checks, and release and documentation publishing jobs. Map which jobs receive secrets, write permissions, checkout credentials, and artifacts; define separate trusted publishing paths and preserve the approval protected QNX workflow. Done means all acceptance criteria pass, including fork PR validation, merge queue runs, and release behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Ordinary PR tests and documentation builds should validate proposed code with minimal permissions, while publication uses a separate trust boundary. Review their current use of pull_request_target independently of the Bazel cache migration in #457.

Current setup
  • test_and_docs.yml uses pull_request_target explicitly to provide secrets to fork runs, checks out the PR head, and executes tests, repository scripts, and documentation builds. Its build job has contents: write and pull-requests: write; release uploads are conditional, but those token permissions apply to the whole job. Documentation deployment is already a separate job.
  • module_tests.yml is called by that workflow with secrets: inherit, checks out the PR head, and executes module tests. It has a read-only token, but receives the optional snapshot-mirror secret through the caller.

For executing proposed code, pull_request_target also means workflow changes in the PR are not exercised by that PR run. GitHub recommends avoiding this event when building or running PR code.

Scope

QNX is excluded from this migration: it requires license material and credentials to build at all, and its secret-bearing runs are protected by an existing approval process. Preserve that approved execution path. This issue does not propose moving QNX to secret-free fork PR builds or replacing its approval mechanism.

Proposed outcome
  • Run ordinary PR tests and documentation builds through pull_request with read-only repository permissions and no repository secrets. Determine how to handle the optional snapshot mirror for those builds.
  • Keep Pages publishing, release uploads, and PR metadata writes in separate trusted jobs or workflows with narrowly scoped permissions. Define how fork PR documentation previews are published without executing PR-provided scripts with publishing credentials.
  • Review inherited secrets, persisted checkout credentials, artifact handoff, cache publication, and required-check names within the tests/docs split. Privileged jobs must not execute scripts supplied by an untrusted build artifact.
Acceptance criteria
  • Ordinary fork PR tests and docs builds work without write tokens or repository secrets.
  • PR changes to those validation workflows are exercised by PR validation.
  • Documentation publishing, required checks, merge-queue runs, and release jobs retain their intended behavior.
  • The existing approval-protected QNX workflow and its required secrets remain functional and outside this change.
  • The cache PR remains limited to caching.
Lingua principale
Python
Stelle
6
Fork
46
Merge medio
2g 3h
PR unite (30g)
29

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-score/reference_integration

Tutte le issue di eclipse-score/reference_integration

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.