Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#74 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, typescript
Área
ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
2
Merge medio
8 h 28 min
PR fusionados (30 d)
26

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PierrunoYT/patch

Todos los issues de PierrunoYT/patch

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.