プロバイダーを公開する

tegata init は、GitHub のリリースからプロバイダーを入れます。このページでは、リリースに何が入っていればよいかを説明します。自分のプロバイダーを公開するときに使ってください（公式のプロバイダーも同じやり方でリリースしています）。

リリースに入れるもの

リリースには v<version> のタグを付け（セマンティック バージョニング。たとえば v0.3.1）、次のファイルを置きます。

ファイル	中身
tegata-provider-<name>_<version>_<os>_<arch>	実行ファイル。アーカイブにはしません。<os> は linux か darwin、<arch> は x86_64 か aarch64。<name> は、使う人の YAML でのプロバイダーの名前
SHA256SUMS	実行ファイルごとに 1 行：<sha256 hex> <file name>（sha256sum か shasum -a 256 の出力）
SHA256SUMS.minisig	SHA256SUMS の minisign の署名

1 つのリリースに、複数のプロバイダーを入れてもかまいません（公式のリリースには全部が入っています）。下書きのリリースと、v<semver> でないタグは無視されます。

使う人は、次のように入れます。

providers:
  example:
    source: github.com/<owner>/<repo>
    version: "^0.3"
    public_key: "<your minisign public key>"

署名の鍵

鍵は一度だけ作ります。

minisign -G -p tegata.pub -s ~/.minisign/tegata.key

• 秘密の鍵は、パスワードで守って自分の機械に置いてください。CI の secrets にもリポジトリにも置かないでください。
• 公開の鍵（tegata.pub の 2 行目）を README に載せて、使う人が YAML に写せるようにします。
• 秘密の鍵をなくしたり漏らしたりしたら、新しい鍵を作り、新しい公開の鍵を知らせ、使う人に public_key を替えてもらってください。tegata は、設定にある鍵以外で署名したリリースを受け付けません。

手順

version=0.3.1
mkdir -p dist && cd dist

# 1. build each provider for each platform, and name the files
#    (for example with cargo and cross, or on one machine per platform)
cp ../target/x86_64-unknown-linux-musl/release/tegata-provider-example tegata-provider-example_${version}_linux_x86_64
cp ../target/aarch64-unknown-linux-musl/release/tegata-provider-example tegata-provider-example_${version}_linux_aarch64
cp ../target/aarch64-apple-darwin/release/tegata-provider-example tegata-provider-example_${version}_darwin_aarch64
# ...

# 2. checksums and signature (asks for the key's password)
shasum -a 256 tegata-provider-* > SHA256SUMS
minisign -S -s ~/.minisign/tegata.key -m SHA256SUMS

# 3. check before publishing
minisign -V -p ../tegata.pub -m SHA256SUMS
shasum -a 256 -c SHA256SUMS

# 4. publish
gh release create v${version} tegata-provider-* SHA256SUMS SHA256SUMS.minisig --title v${version}

知らせる前に、使う人と同じ方法でリリースを確かめられます。ファイルをミラーのディレクトリ（<dir>/github.com/<owner>/<repo>/<version>/）に置き、試しの設定で TEGATA_PROVIDER_MIRROR=<dir> tegata init を流します。

公式のリリースの作り方

k-kawa/tegata の公式のリリース（tegata と、リポジトリの中のすべてのプロバイダー）は、保守する人の機械ではなく GitHub Actions でビルドし、保守する人が署名します。

1. 1 つの PR で、すべての crates/*/Cargo.toml の version を上げ、CHANGELOG.md の [Unreleased] を ## [<version>] - <YYYY-MM-DD> に移し、比較のリンクを足します。マージして、v<version> のタグを push します。
2. .github/workflows/release.yml が、GitHub のマシンで実行ファイルをビルドし（Linux の x86_64 と aarch64 は musl で。macOS は Apple Silicon で両方のアーキテクチャーを）、artifact attestations を付け、SHA256SUMS を書いて、全部を下書きのリリースに置きます。リリースノートは、CHANGELOG.md のその版の節に、ファイルの確かめ方を足したものです（tools/release-notes.sh <version>）。その節がなければ、ワークフローはビルドの前に失敗します。
3. 保守する人が、署名の鍵のある機械で tools/sign-release.sh v<version> を流します。下書きのファイルを取ってきて、SHA256SUMS と attestation で確かめ、リリースノートがあるかを確かめ、SHA256SUMS に署名し、その署名を公式の鍵で確かめ、SHA256SUMS.minisig を置いて、リリースを公開します。

署名の鍵は CI に渡らないので、ワークフローが乗っ取られても、ファイルをビルドすることはできても署名はできません。

リリースのファイルを差し替えない

tegata.lock には、すべてのファイルの SHA-256 が書いてあります。公開した版のファイルが変わると、その版を lock したすべての機械で、tegata init がエラーで止まります。壊れたリリースを直すには、新しい版を出してください。