Skip to content

feat(deploy): add deploy_max_attempts so fnox-based deploys can retry - #487

Open
exKAZUu wants to merge 1 commit into
mainfrom
add-deploy-max-attempts-input
Open

exKAZUu wants to merge 1 commit into
mainfrom
add-deploy-max-attempts-input

Conversation

@exKAZUu

@exKAZUu exKAZUu commented Jul 26, 2026 •

Copy link
Copy Markdown
Member

問題

deploy.yml の Deploy ステップは、デプロイ先を示す secret(FLY_API_TOKEN / RAILWAY_API_TOKEN / GCP_SA_KEY_JSON)がワークフローに渡されたときだけ 20 回リトライし、それ以外は 1 回です。

認証情報を fnox へ移したリポジトリでは、これらの secret を渡さなくなるため、アップロードの一時的な失敗に対するリトライが失われます(WillBooster/coto-world#654 で発生)。デプロイの不安定さは認証情報の置き場所とは無関係なので、この判定は実態と合っていません。

変更

deploy_max_attempts 入力を追加し、呼び出し側が試行回数を明示できるようにしました。未指定時の挙動は従来どおりです(後方互換)。

備考

同じ secret に依存している箇所がもう一つあります: check-gcloud ステップは HAS_GCP_SA_KEY_JSON == "true" を前提としているため、fnox 移行後は gcloud のインストールと認証がスキップされます。coto-world は mise.toml で gcloud を pin し deploy/ci-setup で自前認証しているため実害はありませんが、fnox 移行するリポジトリが増えると問題になり得ます。本 PR のスコープ外とし、必要であれば別途対応します。

The deploy step retries 20 times only when a platform secret
(FLY_API_TOKEN / RAILWAY_API_TOKEN / GCP_SA_KEY_JSON) reaches the workflow.
Repositories that moved those credentials into fnox therefore lost the retry
even though their uploads are just as flaky (WillBooster/coto-world#654).
Let callers set the attempt count explicitly; the default is unchanged.
@gemini-code-assist

Copy link
Copy Markdown

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant