Hatena Blog Tags
はてなブログ トップ
ci
このタグでブログを書く
言葉の解説
ネットで話題
関連ブログ

ci

(コンピュータ)
【しーあい】

Macintosh IIシリーズのミドルレンジマシン。
開発コードネームはAurora II，Cobra II，Pacific，Stingray
CPUはMC68030/25MHz。
cxと同様のメンテナンスしやすい筐体を持つ。
また、グラフィックス機能をはじめてオンボードで搭載した。

このタグの解説についてこの解説文は、すでに終了したサービス「はてなキーワード」内で有志のユーザーが作成・編集した内容に基づいています。その正確性や網羅性をはてなが保証するものではありません。問題のある記述を発見した場合には、お問い合わせフォームよりご連絡ください。
amahisa3のブログ•4日前

CIだけJestが5分終わらなかった原因はTanStack QueryのgcTimeだった

はじめに 環境 何が起きていたのか なぜローカルでは起きなかったのか タイマーを残しているファイルを探す 原因 どう直したか まとめ 参考 はじめに 今回は、React Native(Expo)アプリの開発にてGitHub ActionsのCIでJestのプロセスが5分以上終了しなかった件の調査記録です。 テストはすべて通っていて、実行時間も45秒ほどでした。 それなのにUnit testステップだけが5分以上かかり、ログの末尾には次のようなメッセージが出ていました。 Jest did not exit one second after the test run has completed. …

#Jest#TanStack Query#GitHub Actions#React Native#テスト#CI

関連ブログ

sakuratakashi’s blog•17日前

GitHub ActionsのNode 20終了、`node-version`を24にするだけでは移行できない

CIのNode移行で、最初に.github/workflowsのnode-versionを探したくなる。自分もこの手の変更なら、まずそこを見る。でも今回それだけで「Node 20対応完了」とするのは危ない。workflowでテストするNodeと、uses:先のJavaScript Actionを動かすNodeは別物だ。 GitHubは9月23日、GitHub Actions runnerでNode 20が利用できなくなったと告知した。JavaScript Actionの実行環境はNode 24になり、以前の一時的な回避設定ACTIONS_ALLOW_USE_UNSECURE_NODE_VERS…

#GitHub Actions#Node.js#CI#フロントエンド#開発環境
Algomatic Tech Blog•1ヶ月前

TypeScriptの「型が通る」だけでは足りない。anti-slopで根拠の薄いコードをCIから止める

こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。 TypeScriptの型検査が通ることは大切です。ただし、それだけで実行時の安全まで保証されるわけではありません。 たとえば、次のコードはTypeScript上ではUser型として扱えます。 const user = input as object as User; しかし、このコードはinputの中身を検証していません。objectを経由して、コンパイラへ「これはUserとして扱ってよい」と伝えているだけです。 AIコーディングエージェントによって実装が速くなっても、このような「型エラーにはならない…

#typesciprt#Oxlint#静的解析#型安全#CI#テスト#ソフトウェア設計#AIコーディング
kickflow Tech Blog•1ヶ月前

ビルドは成功、フォントは壊れていた

新規事業本部でエンジニアをしている渡辺です。 本記事では、本番環境でボタンの文字が細く描画されるようになった不具合について、原因特定から再発防止、さらに修正後に生じたパフォーマンス劣化を潰すまでの記録をまとめます。 ひとことで言えば、ビルド時の外部通信が一度失敗しただけで、ビルドは成功したまま成果物だけが壊れていた、という話です。学びが多かったのは原因そのものよりも、「失敗してくれなかったこと」がなぜここまで検知を遅らせたのかという点でした。 1. 何が起きたのか 2. 前提となるフォント配信の構成 3. 調査 3-1. CSS は正しかった 3-2. 日本語サブセットが丸ごと無かった 3-3…

#フォント#Google Fonts#CI
sakuratakashi’s blog•1ヶ月前

AIがコードを書くほど、言語選定は「レビュー予算」で決めたくなる

AIエージェントに小さな実装を任せていると、コードが出てくるまでの待ち時間はほとんど気にならない。代わりに残るのがdiffを読む時間だ。 数十行ならまだいい。関連ファイルを広く触り、テスト修正まで含めて数百行になると、生成の速さはどうでもよくなる。人間側の帯域は増えていない。 この段階で「どの言語ならAIがうまく書けるか」を考え始めると、少し順番を間違える。その言語とrepositoryが、限られた時間内に変更を引き受けるための証拠を返せるか。先に見たいのはこっちだ。 生成量ではなく、レビュー予算を決める ここでいうレビュー予算は、ひとつの変更に使える時間と認知負荷の上限だ。自分なら最低でも次…

#AIコーディング#TypeScript#Go#CI#コードレビュー
sakuratakashi’s blog•2ヶ月前

AIツールのリリースノートを、読むだけで終わらせずCIの入力にする

Gemini APIとGitHubのchangelogを並べて見ると、更新の種類が多すぎる。modelの追加だけではない。parameterの非推奨化、schemaの変更、developer log、IDE側の機能、組織ruleまで、壊れ方の違う変更が同じ「更新情報」として流れてくる。 既読だけでは、保守はほとんど進まない。自分たちのproduct contractのどこが壊れそうかを特定し、該当するcheckを先に走らせたい。自分なら、変更候補を小さなrisk manifestにして、human reviewを通ったものだけCIへ渡す。 「読んだ」と「影響を確認した」は別の状態 AI機能を組…

#生成AI#CI#フロントエンド#Gemini API#GitHub Copilot
so what•2ヶ月前

Atlantisの設定ファイルをサーバを起動せずに検査するatlantis-configtestを作った

atlantis-configtestというCLIを作った。Atlantisのrepos.yamlとatlantis.yamlの構造を、サーバを起動せずに検査する。 Atlantisはrepos.yamlをサーバ起動時にしかパースしないし、atlantis.yamlはプルリクエストのplanを走らせるときにしかパースしない。どちらのtypoも、デプロイの失敗か、他人のプルリクエストに付く失敗コメントになって初めて分かる。同じパーサをCIで先に通しておけば、そこで落ちる。 使い方 サブコマンドは2つで、サーバ側の設定と、リポジトリ側の設定に対応している。 Commands: server-rep…

#Atlantis#Terraform#Go#CI
sakuratakashi’s blog•3ヶ月前

SKILL.md を増やす前に prompt compiler を作ったほうがいい

夜間に coding agent を回していて嫌なのは、派手な hallucination より、普段は通るのに rare path だけで instruction の読み込みが壊れることだ。 SKILL.md を機能ごとに分けた。巨大な AGENTS.md も短くなった。見通しはよくなった。しかし、ある include 先を消しても main path は動く。数日後、別の task がそこを読んで初めて落ちる。 見た目は整理された。でも runtime から見ると、monolith の壊れ方を複数ファイルへ移しただけだ。 prompt や skill を repo で管理するなら、そろそろ…

#AIエージェント#CI#プロンプト#開発環境#フロントエンド
sakuratakashi’s blog•3ヶ月前

TypeScript 7 は速い。でも frontend repo は二段階で移行したほうがいい

TypeScript 7 が出た。Go で書き直された compiler は、full build でだいたい 8〜12 倍速い。 こういう数字を見ると、とりあえず npm install -D typescript して CI の時間を測りたくなる。気持ちは分かる。自分も最初に見るのはそこだ。 ただ、frontend repo で TypeScript を上げる作業は、tsc の差し替えだけでは終わらない。editor がいる。ESLint がいる。Vue なら vue-tsc と language server がいる。Svelte や Astro も template を TypeScr…

#TypeScript#フロントエンド#CI#開発環境#モノレポ