Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

would like an idempotent humility flash with verification

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

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust
領域
cli

調査の方向性

flash コマンドのエントリポイントを特定し、--check と --verify が終了ステータスをどのように決定するかを比較します。要求された冪等モードを追加し、ROM がすでに一致している場合でも検証がステータス 0 で成功するようにします。その後、既存の flash 検証の動作を実行して確認し、通常の非冪等ステータスが変わらないことを確認します。

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

説明

Right now, the humility flash --verify command does almost everything we want: it checks not merely the image ID but also the ROM contents to make sure they match the image. Somewhat regrettably it then exits with a non-zero status code if the image is actually correct, informing the user that they should rerun with --force if they want to rewrite the ROM even though it ostensibly matches.

I think this behaviour is useful in the cases where you expect that the ROM is not correct and want to know if your expectations are not met. However, in manufacturing we have to do basically this every time:

if ! humility flash --check; then
    humility flash --verify
fi

It would be really helpful if there was a humility flash --verify --idempotent (or whatever) that does what flash --verify does today, but which still exits 0 if it did not have to do any work.

主要言語
Rust
スター
587
フォーク
64
平均マージ
2日 1時間
マージ済み PR(30日)
7

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

oxidecomputer/humility のほかの issue

oxidecomputer/humility の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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