Separate ordinary PR tests and docs builds from privileged publishing

Ouverte
  • Quelque chose ne va pas ?
#458 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, python
Domaine
ci-cd, devops

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
6
Forks
46
Merge moyen
2 j 3 h
PR mergées (30 j)
29

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de eclipse-score/reference_integration

Toutes les issues de eclipse-score/reference_integration

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.