リングスター スーパーピッチ クリア L300×W206×H39mm 仕切板20枚付 5個セット SP-3000D-5S cho45
リングスター スーパーピッチ SP-3000D に納めるようにクシ型の仕切りをつくってた。
ジャンプワイヤー整理
ワッシャー用のインナーケース
リングスター スーパーピッチ クリア L300×W206×H39mm 仕切板20枚付 5個セット SP-3000D-5S cho45
リングスター スーパーピッチ SP-3000D というケースをねじの整理に使っている。おおむね良いんだけど、ワッシャーの類だけはどうしても仕切りを超えてややこしいことになることがある。
考えた結果、ワッシャーに関しては蓋つきのインナーケースを作ってハメこむことにしてみた。
GitHub Pull Request Builder Plugin 使っている環境で手元ではテストが通るのに Jenkins では通らない場合
GitHub Pull Request Builder Plugin の PR ブランチビルドの挙動は以下のような状態で実行する
- マージ可能な場合はベースブランチにマージされた状態 (origin/pr/{pr}/merge)
- コンフリクトしている場合はPRブランチのHEAD状態 (commit hash)
表題の「手元ではテストが通るのに Jenkins では通らない場合」は表面上はコンフリクトはしないにも関わらず、ベース側に入った変更によってPRブランチ側が壊れることによって起こる。つまりコード上の意味がコンフリクトしているにも関わらず、表面的にマージされてテストされるため不可解な結果を生むことがある。
解決方法
- ベースブランチをPRブランチにマージする(または rebase する)
- 重要：GitHub 上でコンフリクト表示が出ているか否かは関係ない
PRのテスト結果の表示
GitHub 上に表示されるテスト結果のインジケータには上記のように2つのケースがあり、Jenkins 側のログを見ないと厳密に判断することができない。
GitHub 上での Conflict 表示でもある程度判断できるが、CI を通ったあとにベースブランチに変更が入って Conflict した場合は PR ブランチで再テストが走るまで過去の結果が表示されるため正確ではない。
備考
- origin/pr/{pr}/merge は普通に clone すると含まれないため、Jenkins が存在しない謎のコミットをビルドしているようにみえる