migrate.sh: the seed tag on the default branch triggers tag CI and changes git describe

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, github-actions, javascript
Área
ci-cd, documentation

Línea de trabajo

Start with scripts/migrate.sh around step 2 and trace how PAGES_REF and the seed release are used; then inspect publish-gh-pages.yml to confirm how the release asset is looked up. The proposal is to target the seed tag at the gh-pages commit, but the issue notes this has not been tested. Done means confirming the lookup still works and that the seed tag no longer triggers default branch CI or affects git describe there.

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

Descripción

migrate.sh step 2 creates the pages-default-seed release with gh release create "$SEED_TAG" ... --latest=false (scripts/migrate.sh:237) and no --target, so GitHub creates the tag on the default branch's HEAD. That tag then lives in the default branch's history until step 4 deletes it, which is after the pipeline PR merges. Two things go wrong in the meantime, both seen on DiamondLightSource/python-copier-template during its migration (PR DiamondLightSource/python-copier-template#373):

  1. The tag push runs the old CI. Repos whose CI triggers on tags: ['*'] (every python-copier-template project) run their pre-migration docs workflow for pages-default-seed, which publishes /pages-default-seed/ to gh-pages and adds it to the live switcher.json as a version.
  2. git describe --tags returns pages-default-seed. Anything that derives a version from the nearest tag picks it up. setuptools-scm is unaffected (it only matches tags that look like versions), but copier writes git describe into _commit, so python-copier-template's own tests now render a CONTRIBUTING link to .../python-copier-template/pages/how-to.html (a 404) and its update test hits a merge conflict. Its CI stays red from step 2 until step 4, and step 4 can't run until the pipeline PR has merged and main has built its own docs.

Proposal

Create the seed tag on a commit outside the default branch's history, e.g. --target "$PAGES_REF" (the gh-pages branch the seed is captured from):

  • git describe on the default branch never sees it.
  • A tag push on a gh-pages commit finds no workflow files in that tree, so no CI runs.
  • The seed is only a release asset read by the publish engine, so nothing should depend on where its tag points. I haven't checked this against publish-gh-pages.yml's release lookup.

This is code-read only, not tested on a fork. It may also be worth a line in the migrate how-to warning that, until then, a repo with tags: ['*'] CI should expect the stray version and a describe-based tool may break between steps 2 and 4.

AI Disclaimer

The code and this description were generated with AI and reviewed/tweaked by the author.

Lenguaje dominante
JavaScript
Estrellas
1
Forks
1
Merge medio
3 h 26 min
PR fusionados (30 d)
1

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 DiamondLightSource/myst-version-switcher-plugin

Todos los issues de DiamondLightSource/myst-version-switcher-plugin

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.