Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ci: decide whether the release dry run should run on every push to main

Aperta
  • Qualcosa non va?
#74 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, typescript
Ambito
ci-cd

Direzione di ricerca

Read .github/workflows/release.yml, compare its dry-run triggers with the existing CI test and package jobs, and weigh the listed runtime and coverage tradeoffs. Decide whether to run the dry run on every push, use a cheaper alternative, or keep the current setup; if choosing yes, remove the paths: filter and update the release paragraphs in docs/DEVELOPMENT.md and CHANGELOG.md.

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

Descrizione

ci priority: low question severity: low

The release workflow (.github/workflows/release.yml) now runs a dry run besides tag releases (d50151e): by hand (workflow_dispatch), and on pushes to main and pull requests that change release.yml or package.json. A dry run runs the same tests and builds the same installers, but the Windows installer is unsigned, the tag check is skipped and nothing is released.

It does not run on every push to main. The question is whether it should.

For: every commit would prove the full release path still works on all three platforms: typecheck, unit and end-to-end tests, the Windows NSIS installer, the AppImage, deb and universal DMG, and the packaged node-pty check. A broken release would then show up at the commit that broke it, not when a tag is pushed.

Against:

  • A run takes about 15–20 minutes across three runners, macOS included.
  • Most of it repeats CI: CI's test job already runs the tests on all three platforms, and its package job already builds the Linux and macOS installers on every push.
  • The only extra coverage is the Windows installer build.

Cheaper alternatives:

  • Add a Windows leg to CI's package job (npx electron-builder --win --publish never), which covers the remaining gap.
  • Run the dry run on a schedule (for example nightly) instead of on every push.

If we decide yes: remove the paths: filter under push in release.yml, keeping tags: ['v*'] and branches: [main]. Path filters are not evaluated for tag pushes, so releases are unaffected either way. Then update the release paragraph in docs/DEVELOPMENT.md and CHANGELOG.md.

Lingua principale
TypeScript
Stelle
2
Fork
2
Merge medio
8h 28m
PR unite (30g)
26

Preparare l'ambiente

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 PierrunoYT/patch

Tutte le issue di PierrunoYT/patch

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.