要約

  • GitHub はアーカイブを、全利用者に対する読み取り専用化と、積極的保守ではないことの表示として説明し、解除も認めている。
  • この状態は GitHub 上のリポジトリを対象とし、利用者が実行しているパッケージ、コミット、イメージを特定しない。
  • プラットフォーム上の観測と、利用者自身の退役判断は別々の記録として残す必要がある。

見えている状態が答える質問

アーカイブ表示は強い印象を与える。コード、リリース、issue、タグが残っていても、利用者は「この依存関係は終わった」と読み替えがちである。しかし、その結論には GitHub が観測していない主体と成果物が含まれている。

GitHub の説明によれば、アーカイブ後は issue、pull request、コード、ラベル、マイルストーン、プロジェクト、wiki、リリース、コミット、タグ、ブランチ、リアクション、コードスキャンのアラート、コメント、権限が読み取り専用になる。リポジトリを変更するには解除が必要である。これは所有者が示した保守姿勢と、GitHub の書き込み面についての確かな記録である。

一方で、その表示は、どの利用者がどのバージョンを解決したか、社内ミラーに何があるか、デプロイ済みバイナリが残っているか、代替が選ばれたか、例外を誰が所有するかを示さない。脆弱性、障害、削除義務を立証するものでもない。アーカイブは解除可能であり、削除や利用停止の履歴全体とは異なる。

退役判断には別の対象がある

利用者が扱うのは、レジストリのパッケージ、固定されたコミット、再ビルドした成果物、組み込みコピー、推移的依存関係、コンテナの digest かもしれない。判断には、その実体、利用環境、権限、公開面、代替案、責任者、次回の再確認時点が必要になる。アーカイブ画面はこれらを代行しない。

だからアーカイブはレビューの入力であり、処分結果ではない。調査の結果、利用中の資産に対応しないこともある。置換を予定する場合も、限定的に使い続ける例外を記録する場合も、監視だけを選ぶ場合もある。結論がまだない状態も有効である。バッジを直接「退役済み」に変換すると、誰が何を判断したかが見えなくなる。

GitHub は転送と可視性変更を別の操作として記述している。管理者の変更、fork やアクセスの結果、アーカイブは同じ出来事ではない。いずれも利用者の資産目録や運用判断の代わりにはならない。

観測と決定をつなぐ、二つの記録

観測の記録には、正確なリポジトリ参照、アーカイブまたは解除の状態、観測時刻、情報源を入れる。同時に、それが GitHub の状態についてだけ語ることを明記する。後日の解除は新しい記録として追加し、古い観測を消さない。

決定の記録は利用者が所有する。対象のパッケージ、コミット、digest と、使用状況、検討した根拠、責任者、選択した対応または非対応、再確認条件を結ぶ。これにより、公開されたシグナルを失わず、そこで発生しない権限までシグナルに与えずに済む。

Sources

  1. GitHub Docs — Archiving repositories
  2. GitHub Docs — Transferring a repository
  3. GitHub Docs — Setting repository visibility