ローカルでビルドしてボードに入れる
最終更新
1 行変えてからロボットがそれを動かすのを見るまでのループを、push なし、CI なし、タグなしで回します。増分ビルドで約 1 分、push ＋ CI なら数分です。
そのコマンドが scripts/dev-push.sh です。
最初の 1 回だけ必要なこと
ボードが開発ボードであること。 成果物はチームの dev 鍵で署名されるため、製品版ロボットは --ref と同じ仕組みで拒否します。開発ボードのセットアップを参照。
dev 署名鍵を ~/.duck-keys/team.dev.key に置きます。別の場所なら DUCK_DEV_SECRET_KEY を設定します。
ボード向けにビルドできるツールチェーン。 クロスコンパイラを入れるか:
cargo install cargo-zigbuild --locked
brew install zigあるいは何も入れずに --docker を付けます。動作中の Docker デーモンだけで済み、起動は遅いものの、ボードを手に入れる前に使えるのはこちらだけです。
ループ
scripts/dev-push.sh --name duck-c51b
# あるいはシェルごとに一度
export DUCK_ROBOT=duck-c51b
scripts/dev-push.sh名前は duckctl scan が列挙するものです。アドレスは Bluetooth 経由で尋ねてからキャッシュされるので、キャッシュしたアドレスに届かない push だけが無線に戻ります。DHCP リースの更新、再フラッシュ、別ネットワークへの移動が何のコストもなく追随できるのはこのためです。
何をしているか
ワークスペースをクロスコンパイルし、リリースとまったく同じ成果物にパッケージし、dev 鍵で署名し、ボードの ~/duck-sideload にコピーし、そこで robotctl update apply --from により適用します。その後、全デーモンが新しいリリースを報告するまで待ちます。
出力の中で「異常」に見えて正常なもの
これを知っていると誤読が減ります。
updaterd と btd は apply の応答から 5 秒後に再起動するので、その 2 行は少し遅れて現れます。ハングではありません。
[--] padd published nothing は失敗ではありません。 停止された、あるいは意図的に無効化されたデーモンもこう見えますし、カメラの無いボードの mediad もこう見えます。
[--] tofd published nothing は、tofd が identity を publish するようになる前のリリースであることを意味します——もう一度 push すれば直ります——センサーが無いという意味ではありません。tofd は装着の有無にかかわらず動きます。
これは通常の更新である
署名、成果物のハッシュ、互換性、ヘルスゲート、自動ロールバックがすべて動きます。 起動しないビルドは取り消され、ボードは以前動いていたものに戻ります。意図的に戻すのも通常のコマンドです。
sudo robotctl update rollback daemon同じ dirty なツリーから 2 回 push しても衝突しません——バージョンにはコミットだけでなく push の時刻が入ります。ここではツリーが dirty であることが前提です。
push したものを観察する
push の前に別のターミナルを開いておくと、再起動がそこに現れます。
ssh [email protected] 'journalctl -f -u robotd -u configd -u btd -u padd'-u updaterd だけを見れば更新そのもの——各段階、ヘルスゲート、そしてそれが引き起こす再起動——が見えます。