結論
ChatWork で ChatOps をするのはつらい。
Jenkins から ChatWork へ 通知を飛ばす
以前に書いた、GitLab から ChatWork へ通知を飛ばす の姉妹編です。今度は Jenkins から ChatWork へ通知を飛ばしてみます。
続きを読むChatWork で ChatOps をするのはつらい。
以前に書いた、GitLab から ChatWork へ通知を飛ばす の姉妹編です。今度は Jenkins から ChatWork へ通知を飛ばしてみます。
続きを読むChatWork で ChatOps をするのはつらい。
たとえば GitLab への プッシュ をトリガにして ChatWork へ通知(ポスト)したいとします。現在のところ GitLab 自体に ChatWork へ飛ばす仕組みは組み込まれていません。したがって、Webhook を飛ばすしかありません。しかし、Webhook をどう受けてどう流すか。すべての人がぶち当たる問題です。
続きを読むJenkinsfile
の先頭に以下のコードを記述しましょう。node {
などと同じトップレベルの階層です。
properties properties: [ disableConcurrentBuilds() ]
Jenkinsfile 内のシェルコマンドで、デーモン的なコマンド(バックグラウンドで動作させるようなコマンド)を実行しようとしても実行されない*1。
JENKINS_NODE_COOKIE=dontKillMe
を daemon コマンドの前に付与する。以下、unicorn
を -D
オプションで起動する場合を例にします。
node { stage('deploy') { sh('JENKINS_NODE_COOKIE=dontKillMe bundle exec unicorn -D') } }
検索すると引っかかることが多いのですが、以下のように BUILD_ID=dontKillMe
を付与しても動作しません。node { ... }
の記述法の場合にはこのような書き方では動作しないようです*2。
node { stage('deploy') { sh('BUILD_ID=dontKillMe bundle exec unicorn -D') } }
「node { ... }
の記述法で……」という話が出ましたのですこし付記します。現在では node { ... }
ではなく pipeline { ... }
を用いることが推奨されています*3。詳しくは以下のページをご覧ください。
ローカルネットワーク内に Webhook を飛ばす。
Settings
をクリックSettings
の詳細画面の一番下の Outbound requests
の部分の Expand
をクリックAllow requests to the local network from hooks and services
の項目にチェックを入れるSave changes
ボタンを押して適用させる
最近のバージョンから、ローカルネットワークへ Webhook を飛ばすためには上記の手順が必要になったとのことです*1。今回も Stack Overflow に助けられました。
この画面が現れるといつもドキッとします。
*1:ローカルでなければ上記の手順は不要です