Jenkinsの環境変数のバグにはまる
Jenkinsで使われる環境変数には似たようなものが有ってややこしいが、次の定義になっている。
Building a software project - 日本語 - Jenkins Wiki
BUILD_NUMBER "153"のような現在のビルド番号。 BUILD_ID "2005-08-22_23-59-59" ( YYYY-MM-DD_hh-mm-ss 形式)のような現在のビルドのID。
要するに"NUMBER"はシリアル番号で、"ID"は日時というわけだ。必要と目的に応じて、この両者を使い分ければ良い。例えば、リリースのファイル名に付けるなら「何回目のリリースなのか」分かるようにBUILD_NUMBERを使っているし、バックアップのファイル名に付けるなら「いつのバックアップなのか」分かるようにBUILD_IDを使っている。両方ともに便利だ。
しかしながら、ある時、Jenkinsのジョブで生成されたバックアップにビルド番号が付けられていることに気がついた。スクリプトを変更したはずはないのに、いつの間にかBUILD_IDとしてBUILD_NUMBERのビルド番号が出力されているのだ。これは変だ。
調べたところ、Jenkins自身のバグと分かった。
With this release jenkins changed the build identifier to the build number (instead of timestamp). Now the BUILD_NUMBER and BUILD_ID both return the build number and there is no way to get the timestamp from the environment variables.
[JENKINS-26520] Environment Variables BUILD_ID and BUILD_NUMBER now return the same value - Jenkins JIRA
According to the documentation BUILD_ID should return the timestamp.
Issueの"Component/s:"というカテゴリは"core”になっており、確かにこれはコア機能だ。まさかこんな所にバグ（デグレ）が発生するとは全くの想定外で、ファイル名の日時をキーに使う後続処理は軒並み影響を受けていた。仕方ないので自前でタイムスタンプを生成して代用したけど、落とし穴はいつ何処で待ち構えているか分からないから気をつけましょうというのが今日の結論でした。
