つばくろぐ @takamii228

知は力なり

JenkinsのMultibranch PipelineではGitLabのtag pushビルドが走らない

Multibranch PipelineでTagが拾えるようになったらしい

Multibranch PipelineジョブのJenkinsfileの中で、when句にtagが使えるらしい。

jenkins.io

これを使えばレポジトリへのtag Pushを契機にリリース資材をライブラリに追加したりS3に配置したりなんてことが可能になる！と思ったので試してみました。

GitLabでは自動実行されなかった

GitLabとJenkinsの連携手順は以下を参照。

Webhookの発行のところのTriggerのTag Pushにチェックを入れればGitLabからJenkinsへWebhookが飛ぶようになります。

qiita.com

実際にtag pushしてみましたが、Git PluginがTagに対応しているので、Tagに応じてジョブをdiscoverするものの自動実行されませんでした。

ログを見る限りWebhookは飛んでいるもののJenkinsがうまく受け取れていないようです。

GitLabプラグインの中を見てみる

README.mdにtag pushについては以下のことしか書いてなかった。

In order to build when a new tag is pushed:
1. In the GitLab webhook configuration, add 'Tag push events'
2. In the job configuration under 'Source code management':
i. Select 'Advanced...' and add '+refs/tags/:refs/remotes/origin/tags/' as the Refspec
ii. You can also use 'Branch Specifier' to specify which tag need to be built (example 'refs/tags/${TAGNAME}')

これはフリースタイルでジョブを作ったときの設定で、Multibranchに対する記述はありません。

github.com

ソースコードを読んでみても、TagPushTreggerに関するコードは見当たらなかったので実装がないっぽい。

gitlab-plugin/GitLabPushTrigger.java at master · jenkinsci/gitlab-plugin · GitHub

...
    private boolean triggerOnPush = true;
    private boolean triggerOnMergeRequest = true;
    private boolean triggerOnPipelineEvent = false;
    private boolean triggerOnAcceptedMergeRequest = false;
    private boolean triggerOnClosedMergeRequest = false;
    private boolean triggerOnApprovedMergeRequest = false;
...

他にも困っている人がいた

ググると騒いでいる人々を発見。やはりできないっぽい。

回避方法

仕方ないのでブランチPushでブランチ名からtag名を取得して、Jenkinsfile内部でtagをレポジトリへpushするように設定した。

やり方はこちらを参考にした。

int128.hatenablog.com

GitLab APIとGitHub APIは結構違う

ドキュメントを見るとGitLabとGitHubのAPIのパラメータは構造もパラメータ名も結構違う。

世の中の大半はGitHubで動いてるっぽいので、GitLab勢にとっては世知辛い。

GitLabのWebhookをGitHub API互換に変換する何かがあるとみんな幸せになったりするのだろうか🤔🤔🤔

Kubernetesでhelm deleteとhelmfile deleteを間違えて事故った話

はじめに

で起きたことを懺悔としてまとめます。

前談

今のプロジェクトで運用しているKubernetesクラスターはAWS上にkopsで構築しています。

また各chartをパッケージマネージャであるhelmで管理していて、chartの定義をhelmfileで管理しています。

github.com

Releaseを再作成しようとして実行するコマンドを間違えた

今回とあるServiceに対してKubernetesのserviceとdeploymentのyamlをダッシュボードからいじった結果、helmfile syncに失敗する状態になってしまったので、 helm経由でReleseを作り直そうとしました。

私はまだKubernetesやhelmの操作に慣れていなかったため、誤ってhelmfile delteとhelm deleteコマンドを間違えてしまいました。

# 本来打つべきコマンド
helm delete xxxxxx

# 実際に打ったコマンド
helmfile delete xxxxxx

helmコマンドではリンクの通り、RELEASE_NAMEを指定することで特定のchartのみ削除することができます。

helm delete [flags] RELEASE_NAME [...]

docs.helm.sh

helmfile delete xxxxxを打ったあとに、以下の表示が出ました。

release aaaaa deleted
release bbbbb deleted
release ccccc deleted
release ddddd deleted
release eeeee deleted

あれ🙁？

Kubernetesで管理している各サービスにアクセスすると....

f:id:takamii228:20180703222139p:plain

😨😨😨

f:id:takamii228:20180703222139p:plain

😱😱😱😱😱😱

全部消えとるがなー！！

helmfileのREADME.mdを確認すると

delete delete charts from state file (helm delete)

ぜ、全部消えるんかい。。。

github.com

幸いにも作り直そうとしてるService意外にアタッチしていたPVCのpersistentVolumeReclaimPolicyをRetainにしていたので、再度helmfile syncしてPVCをアタッチしなおすことで即座に復旧するとができました。

もしpersistentVolumeReclaimPolicyがデフォルトのDeleteだった場合は今まで設定したものが全部吹っ飛ぶことになっていたと思うと背筋が凍りました。

Issueを上げてもらった

github.com

私みたいな被害者が今後出ないことを切に祈ります 🙏

教訓

  • 不慣れなコマンドはちゃんと確認してから実行するべし。

Swift愛好会 vol.31 で談義した #love_swift

Swift 愛好会 vol.31 に参加して、もくもく作業をしたあとに、「プライベート開発を継続する技術」というタイトルで談義発表しました。

love-swift.connpass.com

七島さんのツイートにもありましたが、何かを決意してやり続ける、ということを成し遂げるには、共通するメタな何かかがあるのだなぁということを感じましたまる。