tech

結論 式は、存在しない値を参照してもエラーにせず空文字を返す。未登録の secret も、skip された step の output も '' になる with: に空文字を渡すと action.yml の default は使われず、空文字がそのまま action に届く。hashicorp/setup-terraform は最新版を入れ、actions/checkout は起動したイベントの ref を取る。どちらも失敗しない step の env: は if: より先に評価される。skip させるつもりの step でも、空文字を fromJSON() に通すとその step が落ちる if: failure() は job のキャンセルと job の timeout-minutes 超過では走らない。後片付けは if: always() に置く shell: を書かない run と、shell: を自前の文字列に書き換えた run には pipefail が付かない 空文字は受け取る側では気付けない。値を作る step で空を落とし、真偽値の output は true / false 以外を落とす 以下は公式ドキュメントと、actions/runner v2.337.0 / actions/checkout v7.0.1 / hashicorp/setup-terraform v4.0.1 / tj-actions/changed-files v47.0.6 のソースで確かめた。ワークフローを実際に走らせて測ったものではない。 ...

結論 git rebase main は、ブランチにあって main に無いコミットを、main の先頭へ 1 本ずつ cherry-pick し直す。git はブランチの派生元を記録しないので、どこから先を載せるかは毎回コミットグラフから求める rebase の後は git merge-base main HEAD が main の先頭を返す。元の分岐点を後で使うなら rebase の前に控える 競合中の --ours は main 側、--theirs は自分のコミット。merge と逆になる 競合しなかったことは、整合していることを意味しない。main が入れた改名や規約は、競合しないファイルには届かない squash merge の後や載せるコミットが 0 件のときは、どこから先を載せるかの推定がずれて、衝突やブランチ先頭の移動が起きる。--onto で起点を明示する autostash の書き戻しが衝突しても、rebase も pull --ff-only も exit 0 で終わる 以下はすべて git 2.55.0 で実測した。pull.rebase や rerere.enabled などの利用者設定で結果が変わるので、GIT_CONFIG_GLOBAL=/dev/null で ~/.gitconfig を読ませずに実行している。 前提: rebase は分岐点から先を作り直す git rebase <upstream> は次の 4 段で動く (man git-rebase)。 今のブランチにあって <upstream> に無いコミットを並べる。<upstream> に同じ変更 (patch-id が一致するコミット) があるものは外す <upstream> の先頭を detach でチェックアウトする 並べたコミットを 1 本ずつ cherry-pick する ブランチをできあがった先頭へ付け替える 1 の範囲は git log <upstream>..HEAD と同じで、分岐点から先にあたる ( git logの「..」と「…」の違い )。 ...

結論 make は Makefile をすべて読み込んで依存グラフを作ってから、レシピを実行する。:= の右辺、ルールの前提条件、include の作り直しは読み込みの段階で走る make は失敗をほとんど報告しない。未定義の変数は空文字になり、.PHONY に名前だけあるターゲットやファイルが既にあるターゲットは「やることなし」で exit 0 になる レシピは既定で /bin/sh が実行し、pipefail が無い。シェルのメタ文字が無い行はシェルすら通らない 前提条件の並び順は実行順ではない。順序は依存関係か .WAIT で書く 外から来た値を $(shell ...) に埋めると、値がコマンドとして実行される 以下のコードはすべて GNU Make 4.4.1 で実測した。 前提: 読み込みと実行の 2 段階 GNU make は 2 つの段階で動く。 読み込み: include 先を含む全 makefile を読み、変数とルールを取り込んで依存グラフを作る 実行: グラフから更新が要るターゲットを決め、レシピを実行する 展開には、読み込みの段階で行う「即時」と、値が使われるまで遅らせる「遅延」がある。 構文 即時に展開 遅延 VAR = value 左辺 右辺 (参照されるたびに展開) VAR ?= value 左辺 右辺 VAR := value 左辺と右辺 - target: prereq ターゲットと前提条件 - レシピ - 全体 以下の罠の多くは、この表と違うタイミングを想定して書いたときに起きる。 ...

結論 set -e は「条件の文脈の外で、コマンドが非 0 を返したら止まる」だけの仕組みで、失敗を報告はしない 効きすぎる: 関数の戻り値、x=$(cmd) の代入、((n++))、wait、read が非 0 を返すと、メッセージ無しでその行で終わる 効かない: && / || の途中、if / while の条件、そこから呼んだ関数と subshell の中、$( ) の中、set -e より前の行 失敗の扱いは set -e 任せにせず、その文に || return 1 や || fallback を付けて明示する 以下のコードはすべて GNU bash 5.3.15 で実測した。 前提: set -e が止めない文脈 bash は、失敗したコマンドが次のどれかに当たるとき set -e で終了しない。 while / until の直後のコマンドリスト if / elif の条件 && / || のリストの途中 (最後以外) ! で反転したコマンド この免除は、その文脈で実行される関数本体と subshell の中まで及ぶ。 逆に、この文脈の外で非 0 を返した文は、関数呼び出しでも代入文でも止まる。 ...

Firebase Hosting + Cloud Run で認証が動かない？Cookie名を __session にすべき理由 TL;DR Firebase Hosting 経由で Cloud Run にアクセスする場合、セッション Cookie の名前は 必ず __session にする必要がある。それ以外の名前（session, auth, token など）は Firebase Hosting (CDN) によってストリップ（削除）され、バックエンドに届かない。 問題の症状 Next.js アプリを Firebase Hosting + Cloud Run で運用している際、以下のような不可解な現象に遭遇した： ✅ Cloud Run の URL（https://<service>-<hash>.run.app）では正常にログインできる ❌ Firebase Hosting の URL（https://<project>.web.app）ではログインできない Set-Cookie ヘッダーは正しく返されている ブラウザの Application タブでは Cookie が設定されている しかし Middleware では Cookie が undefined になる 根本原因：Firebase Hosting の Cookie 制限 Firebase Hosting は CDN として動作する Firebase Hosting は静的コンテンツ配信のために CDN（コンテンツ配信ネットワーク）として動作する。CDN はキャッシュ効率を最大化するため、デフォルトで全ての Cookie をストリップ（削除）する。 ...