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

オープン
#83 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
git, github-actions, javascript

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
JavaScript
スター
1
フォーク
1
平均マージ
3時間 26分
マージ済み PR(30日)
1

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DiamondLightSource/myst-version-switcher-plugin のほかの issue

DiamondLightSource/myst-version-switcher-plugin の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。