Separate ordinary PR tests and docs builds from privileged publishing

Offen
  • Stimmt etwas nicht?
#458 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python
Bereich
ci-cd, devops

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Python
Sterne
6
Forks
46
Ø Merge
2 T. 3 Std.
Gemergte PRs (30 T.)
29

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus eclipse-score/reference_integration

Alle Issues in eclipse-score/reference_integration

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.