トラブルシューティング

最も遭遇しやすい問題への実用的な修正方法です。

認証の失敗

コマンドが認証エラーを返した場合、CLI が解決しているアイデンティティ（あれば）を確認します:

suya auth whoami     # calls the API and prints the resolved identity
suya auth status     # local auth status, no server call

エージェントと CI の場合は、suya を実行するシェルで SUBAYA_API_KEY がエクスポートされていることを確認してください:

echo "${SUBAYA_API_KEY:?SUBAYA_API_KEY is not set}"

認証情報の優先順位を覚えておいてください: --token フラグが勝ち、次に SUBAYA_API_KEY、次にローカルに保存された OAuth トークンです。ずっと前にログインした場合は、新しい suya auth login でローカルトークンが再確立されます。認証と API キーをご覧ください。

コマンドが誤ったホストに当たる

すべてのコマンドはデフォルトで https://subaya-dev.com と通信します。リクエストが失敗したり予期しない場所に着地したりする場合は、不要な --host を渡していないか確認します:

suya auth whoami --host https://subaya-dev.com

--host は、デフォルト以外の API エンドポイントをターゲットにするつもりのときにのみ上書きしてください。

`suya sim run` がテストベンチを見つけられない

--tb パスは、シェルの作業ディレクトリからの相対ではなく、--source ツリーの中で解釈されます。実行がテストベンチの欠落を報告する場合、パスがアップロードするソースディレクトリの中で解決することを確認します:

suya sim run --source . --tb tb/top_tb.sv --top top --tool ryusim

確認すべき 2 つの点:

--tb パスが --source ディレクトリの下に存在すること。
--source ツリーが 4 MB 以下であること — 送信前にビルドアーティファクトと大きなバイナリファイルを取り除いてください。

完全なシミュレーションサーフェスについては CLI: sim をご覧ください。

`suya repo connect` / `repo create` が失敗する

どちらの repo コマンドも --installation 経由で GitHub App のインストール id を必要とします:

suya repo connect --installation <id> --owner <o> --repo <r>
suya repo create  --installation <id> --name <n>

まだインストール id を持っていない場合は、まず GitHub App をインストールしてください — GitHub リポジトリを接続を参照。現在の接続状態を次で確認します:

suya repo status

古い CLI

コマンドやフラグが欠けていたり、動作がこれらのドキュメントと一致しなかったりする場合、CLI が古くなっている可能性があります。確認してアップグレードします:

suya version            # show version metadata
suya update --check     # report whether a newer release exists
suya update             # upgrade to the latest release

まだ解決しませんか?

追加の診断のために -v/--verbose を付けて再実行するか、機械可読の出力のために --json を使います。
Status ページでサービスの健全性を確認します。
CLI リファレンスで完全なコマンドサーフェスを閲覧します。