久しぶりにJenkinsプラグインをリリースしようとしたら謎のエラーで失敗した

Qiitaや会社ブログにはエントリ書いてたけどこっちのブログは1ヶ月間更新無しとかマジか。（挨拶）

前置き

先日自分がメンテしてるJenkinsプラグインにPRがきて「よっしゃ！マージしてリリースするぜ！」と思っていつものリリースコマンド *1 をたたいたらリリース時に謎のエラーがおきて途方に暮れていた時の出来事です。

日本語だと今回の事象が見つからなかったので日本語でメモ残しておきます

tl;dr

org.jenkins-ci.plugins.plugin（全てのJenkinsプラグインの親プラグイン）を2.5以降にしよう

エラー内容

[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ gitlab-logo ---
[INFO] [INFO] Installing /Users/sue445/dev/workspace/github.com/jenkinsci/gitlab-logo/target/checkout/target/gitlab-logo.hpi to /Users/sue445/.m2/repository/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2.hpi
[INFO] [INFO] Installing /Users/sue445/dev/workspace/github.com/jenkinsci/gitlab-logo/target/checkout/pom.xml to /Users/sue445/.m2/repository/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2.pom
[INFO] [INFO] Installing /Users/sue445/dev/workspace/github.com/jenkinsci/gitlab-logo/target/checkout/target/gitlab-logo.jar to /Users/sue445/.m2/repository/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2.jar
[INFO] [INFO] Installing /Users/sue445/dev/workspace/github.com/jenkinsci/gitlab-logo/target/checkout/target/gitlab-logo-sources.jar to /Users/sue445/.m2/repository/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2-sources.jar
[INFO] [INFO] Installing /Users/sue445/dev/workspace/github.com/jenkinsci/gitlab-logo/target/checkout/target/gitlab-logo-javadoc.jar to /Users/sue445/.m2/repository/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2-javadoc.jar
[INFO] [INFO]
[INFO] [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @ gitlab-logo ---
[INFO] Uploading: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2.hpi
[INFO]
[INFO] Uploading: http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jenkins-ci/plugins/gitlab-logo/1.0.2/gitlab-logo-1.0.2.pom
[INFO]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 3:57.988s
[INFO] [INFO] Finished at: Thu Oct 27 08:50:12 JST 2016
[INFO] [INFO] Final Memory: 71M/499M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on project gitlab-logo: Failed to deploy artifacts: Could not transfer artifact org.jenkins-ci.plugins:gitlab-logo:hpi:1.0.2 from/to maven.jenkins-ci.org (http://maven.jenkins-ci.org:8081/content/repositories/releases): Connection to http://maven.jenkins-ci.org:8081 refused: Operation timed out -> [Help 1]

うーん、http://maven.jenkins-ci.org:8081 にプラグインアップロードする時にタイムアウト？？？？

エラー全文 https://gist.github.com/sue445/259d4c71d2e4d34b33948cb61c66a900

原因

プラグインのアップロード先が http://maven.jenkins-ci.org:8081 から https://repo.jenkins-ci.org に変わったため

ソース

原因が見つかったのは https://issues.jenkins-ci.org/browse/JENKINS-37423 の下記のコメントを見つけたのがきっかけでした。（このきっかけを見つけるまで約1週間かかった）

CrossBrowserTesting.com LLC added a comment - 2016/Aug/22 11:23 PM fixed it. had to update the parent to version of at least 2.5 in pom.xml https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Workingaroundcommonissues

で、リンク先には

Either overwrite the repository location in your POM to point to https://repo.jenkins-ci.org, or update to the parent plugins POM 2.5 or newer

って書いてた。親プラグインのバージョン上げずにPOMのアップロード先だけ変えるってのが分からなかったので正攻法に親プラグインのバージョンを上げることに。

実際に対応したのがこのPR

github.com

この修正でプラグインをリリースすることができました

org.jenkins-ci.plugins.pluginのバージョンを上げるとBetamaxがうまく動かない問題

Betamaxというのはhttp通信をモック化するGroovy製のライブラリです。自分のプラグインだとGitLabの通信部分をスタブにするために使っていました

betamax.software

上記PRでbetamaxを消した理由をメモ

1. org.jenkins-ci.plugins.pluginのバージョンを上げるとつられてJettyのバージョンも上がって、betamaxの中で使ってるJettyのバージョンが古すぎてビルドでエラーになる
2. betamaxのバージョンを1系から2系に上げると今度はSSLのモックがうまく効かない
3. 公式のドキュメント 読むと「 keytool -importcert 〜 でbetamaxの鍵を追加すると動くようになるよ」って書いてある
4. しかし自分で管理してるJenkinsならまだしもcloudbeesのJenkinsでそれは無理ぽ

ってことでbetamaxを捨てて昔ながらにStubクラスからテスト対象のクラスを継承してテストするようにしました

github.com

*1:mvn release:prepare release:perform

Jenkinsを安全にアップデートする方法

手持ちのJenkinsをいくつかアップデートすることがあったので備忘がてらまとめておきます。*1

Jenkins 1系 -> 2系などの大幅アップデートに限らず、プラグインのアップデートでも使えると思います。

事前にやるべきこと

アップデート後に何か問題があって戻さざるを得ないこともありうるので、すぐに元に戻せる状態にしておきます。*2

Jenkins本体のバックアップ

jenkins.warをそのまま使ってる場合

jenkins.warをどこかにバックアップするか、アップデート前のバージョンをどこかにメモっておいてください。

jenkins.warの過去バージョンは http://mirrors.jenkins-ci.org/war/ からダウンロードできます。

yumやaptを使ってる場合

yum install や apt-get install では最新版しかインストールされないので、ロールバックも考慮するとパッケージ指定でインストールした方がいいと思います。

rpmやdebはこちらからダウンロードできます

• http://pkg.jenkins-ci.org/redhat/
• http://pkg.jenkins-ci.org/debian/

ちなみにパッケージからインストールしておくとjenkinsユーザ作ってくれたりデーモン化までやってくれるのでおすすめです

自分の場合こういうitamaeレシピ書いてます（Debian版）

jenkins.rb

execute "wget http://pkg.jenkins-ci.org/debian/binary/jenkins_#{node[:jenkins][:version]}_all.deb -P #{node[:jenkins][:deb_dir]} && dpkg -i #{node[:jenkins][:deb_dir]}/jenkins_#{node[:jenkins][:version]}_all.deb" do
  not_if "ls #{node[:jenkins][:deb_dir]}/jenkins_#{node[:jenkins][:version]}_all.deb"
end

node.yml

jenkins:
  version: "2.8"
  deb_dir: "/data/backup/jenkins_deb"

コマンドに書き下すとこんな感じ

cd /path/to/backup_dir
wget http://pkg.jenkins-ci.org/debian/binary/jenkins_2.8_all.deb
dpkg -i jenkins_2.8_all.deb

この場合でも戻す場合は過去バージョンのrpmやdebでインストールしなおすだけです

最初ymlでバージョン変えてitamae実行したのですが、 /etc/default/jenkins で JENKINS_HOME やJVMのメモリ割り当てで編集してた関係で差分適用するかどうかの入力待ち*3でずっと止まってたので、もしかしたら手動の方がいいかもしれないです。

プラグインや設定一式のバックアップ

手前味噌ですが jenkins-backup-script を使うのがいいです。設定ファイルやプラグイン一式全部バックアップされます。

sue445.hatenablog.com

こういう風にジョブ登録しておいて1日1回夜中に定期実行したり、Jenkins本体やプラグインのアップデート前に手動実行したりしています。

一応tarは外部のバックアップサーバにも転送してるので、突然Jenkinsマシンが死んでもすぐに復旧できる状態にはなってます

Jenkins本体はそうでもないのですが、プラグインは稀に下位互換性をぶっ壊すような変更が入るのでバックアップは必須かと *4

アップデート手順

warなりdebなりrpmなり最新版でインストールし直すだけ。

確認方法

主要なジョブをいくつか手動実行してみる

戻す方法

• jenkins.warを使ってる場合は過去バージョンのを置き直すだけ
• rpmやdeb使ってる場合は過去バージョンでインストールしなおすだけ
• jenkins-backup-scriptは下記のようなコマンドで設定ファイルを上書きするだけ

cd /path/to/backup_dir
tar xzvf backup.tar.gz
sudo cp -R jenkins-backup/* /path/to/jenkins/
sudo chown jenkins:jenkins -R /path/to/jenkins/

アップデート時にハマったこと

Branches to build で変数が取れなくなった

jenkins-gitlab-merge-request-builder-plugin を使ってた時にビルド対象のブランチ名がとれなくなったハマりました

設定

正常な時のログ

20:11:03  > git rev-parse refs/remotes/origin/feature/remove_alias_method_chain^{commit} # timeout=10
20:11:03  > git rev-parse refs/remotes/origin/refs/remotes/origin/feature/remove_alias_method_chain^{commit} # timeout=10
20:11:03 Checking out Revision 4e9593d92e293c5ca99eaa6de3b92b973cb1716a (refs/remotes/origin/feature/remove_alias_method_chain)
20:11:03  > git config core.sparsecheckout # timeout=10
20:11:03  > git checkout -f 4e9593d92e293c5ca99eaa6de3b92b973cb1716a

エラー時のログ

19:09:00 Gitlab Merge Request #9222 : xxxx/my_xxxx/feature/update_ruby => master
19:09:01  > git rev-parse refs/remotes/origin/${gitlabSourceBranch}^{commit} # timeout=10
19:09:01  > git rev-parse refs/remotes/origin/refs/remotes/origin/${gitlabSourceBranch}^{commit} # timeout=10
19:09:01  > git rev-parse refs/remotes/origin/${gitlabSourceBranch}^{commit} # timeout=10
19:09:01 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

GitLabのwebhookからJenkinsにブランチ名は渡されてるっぽいのだけど、 git rev-parse する時にはブランチ名がとれなくなってるような挙動。

「明示的に設定したパラメータしか変数としてバインドされなくなったのかなー」と思って「ビルドのパラメータ化」のところに gitlabSourceBranch を定義したらビルドが動くようになりました。*5

所感

• 1系 -> 2系のアップデートで身構えてたけど、アップデート自体は驚くほどサクッとできました
• パイプラインやJob DSLに全部置き換えるとかだと大変そうだけど、既存のジョブをそのまま移行する分には問題なさそうです
• とはいえ保険が多いにこしたことはないのでバックアップはしておいた方がいいです

まとめ

• 何かあった時のロールバック手順は必ず用意しておく（石橋を叩いて渡るくらいが丁度いい）
• Jenkins 2系はいいぞ

ブコメレス

id:C_L

JenkinsCIををrpmでアップデートすると、$JENKINS_HOMEをchown -Rする糞コマンド入っているので、workspace/以下を綺麗にしておくかexport JENKINS_INSTALL_SKIP_CHOWN=trueしておかないと何時間もupdate終わらんとかになる

ナルホディウス。debだと時間かかっていなかったのでプラットフォームごとに違うのですね。（自分のところのJENKINS_HOME配下もファイル数カオスなので一瞬でchown -Rが終わるとも思えない）

*1:Jenkins 3つ管理してて、それぞれ1.6系から2.8へのアップデート

*2:過去にアップデートしたらダッシュボードが全部吹っ飛んで、バックアップもなかったので脳内ソースを頼りに半日がかりで復旧したことがあります(;´Д｀)

*3:上書きしますか？(y/n)的なやつ

*4:http://sue445.hatenablog.com/entry/2016/01/20/232500

*5:リリースノートちゃんと追ってないのでどこで変更あったかは不明

Gitlab Merge Request Builder Plugin で Could not merge が出た時の対処法

tl;dr

Jenkins上でマージするのを諦めよう

github.com

使ってるバージョン

• Jenkins v1.643
• Gitlab Merge Request Builder Plugin v2.0.0
• Git client plugin v1.19.1
• Git plugin v2.4.1

エラー詳細

こんな感じのエラーです

19:58:57  > git rev-parse origin/develop^{commit} # timeout=10
19:58:57  > git config core.sparsecheckout # timeout=10
19:58:57  > git checkout -f origin/develop
19:58:57  > git merge -s recursive --no-ff 70659b22c6503833c8d3f71b7754dd3e16e2d71e # timeout=10
19:58:57  > git config core.sparsecheckout # timeout=10
19:58:57  > git checkout -f 70659b22c6503833c8d3f71b7754dd3e16e2d71e
19:58:57 ERROR: Branch not suitable for integration as it does not merge cleanly: Could not merge AnyObjectId[70659b22c6503833c8d3f71b7754dd3e16e2d71e]
19:58:57 Finished: FAILURE

大した差分でもないしGitLab上でもコンフリクト起こしていないしアクセプトボタンも押せる状態なのに、なぜかJenkins上でマージできずにエラーになるということがたまにありました

2年くらい使ってる自分の経験則では

• fast forwardでマージできる場合にはエラーは起きないが、fast forwardでマージできない場合にエラーになる
• MergeRequestのsource branch（送り元のトピックブランチ）とtarget branch（送り先のブランチ）の差分が大きいとエラーになりやすい

という感じでした。

Git flowを使っている場合に、リリースブランチからdevelopブランチへのマージ*1は問題ないのに、masterブランチへのマージ*2でエラーになるのでなかなか厳しいものがありました。（つらい）

エラーが発生してる場所

Jenkinsのコンソールログだけだと特定しづらかったですが、JGitでのマージに失敗してるようでした。 https://github.com/jenkinsci/git-plugin/blob/git-2.4.2/src/main/java/hudson/plugins/git/extensions/impl/PreBuildMerge.java#L76

そりゃJenkinsサーバのgitのバージョンを上げても直らないわけだ。。。

設定をいろいろいじった

思いっきし「This feature is not fully implemented in JGIT.（この機能はJGITでは完全にサポートされていない）」って書いてるなｗ

Fast-forward modeを --no-ff にした状態でMerge strategyは全種類試しましたが解決しませんでした。。。

対処法

Additional Behavioursを消した

Before

Gitlab Merge Request Builder Pluginのドキュメントに書いてる設定

After

修正後

Merge before buildを削除。要はsource branchをtarget branchにマージした状態でテストするのではなく、source branch自体をテストするというわけです

「マージした状態でビルドしなくて大丈夫か？」とも思うかもしれませんが、

• 差分がでかい時にマージエラーが起きるくらいならマージしないでビルドしたい
• ビルドに時間がかかるとrebaseしてビルドし直すコストが高い *3
• マージした先のdevelopブランチやmasterブランチもJenkinsでビルドをしている *4

と判断で外しました。

ちなみに同プラグインのGitHub版の GitHub pull request builder plugin だと ${sha1} （マージしない状態のPullRequestのコミットID）でテストをしていました

しばらく運用してみた

上記設定で1週間くらい運用してみました

ビルドスクリプトを修正してmasterにコミットした時にトピックブランチ側が古い状態でビルドしてエラーになることがありましたが、それ以外はそれなりに快適にやってます。まぁその辺はトレードオフなんじゃないかと。

*1:差分はCHANGELOGくらい

*2:developに比べたら差分はたくさんある

*3:今メインで開発してるアプリだと1ビルド10分前後

*4:MergeRequestをビルドしているような人がmasterブランチをビルドしないわけないｗ

Jenkinsを使った最高のマトリックステスト（2016年版）

マトリックステストとは？

複数のパラメータを掛けあわせてテストを実行することです

（例：Ruby 2.1系、2.2系、2.3系 x Rails 4.2系、5.0系 = 計6パターンのテストを行うこと）

Travis CIの方がもっと手軽に行う事ができるのでOSS開発の場合はそっちを使うといいと思います

参考

sue445.hatenablog.com

マトリックステストの行い方

「新規ジョブ作成」で「マルチ構成プロジェクトのビルド」でプロジェクトを作成します

「マトリックスの設定」でテストしたい軸とパラメータを記述するだけです

実行結果

実際にジョブを実行するとこういう風になります

マトリックスの設定で設定したパラメータはジョブ実行時に環境変数にセットされているので、スクリプト内でrbenvとかによしなに渡してやればそのパラメータでテストを行うことができます

スクリプト

結果

問題点

Jenkinsでも簡単にマトリックステストが実践できますがいくつか問題点があります

軸の設定をジョブにハードコーディングする必要がある

ジョブが1つだけならいいんですが同じリポジトリで複数のジョブを作成した時に、パラメータを追加したい時は全てのジョブに設定を反映させる必要があります

除外設定が面倒

特定の組み合わせだけテストを除外したい（例：Ruby2.1系ではRails 5.0は動かないのでテストする必要ない）ような場合に、標準で使える「組み合わせフィルター」だとGroovy式で設定する必要があります *1

右上はスキップされたので色が薄いです

できないことはないのですが、複数条件になると見づらいし、さっきと同様ジョブにハードコーディングされているので条件変えたい時に全てのジョブに手動で反映させる必要があります。

俺はTravis CIみたいにリポジトリにコミットしたymlファイルでテストしたいんじゃああああああ！！！１１１１１

というわけでJenkinsプラグインを作りました

Yaml Axis Plugin - Jenkins - Jenkins Wiki

github.com

先日ブログにも書いたので記憶に新しい人もいると思います。

sue445.hatenablog.com

今日リリースした v0.2.0でパラメータの特定の組み合わせのみ除外することもymlでできるようになりました！（Travis CIの matris.exclude とほぼ同等の機能）

使い方

こういうyamlファイルをリポジトリにコミットしておいて

# axis.yml
RUBY:
  - 2.1.8
  - 2.2.4
  - 2.3.0

RAILS:
  - 4.2.0
  - 5.0.0.beta2

exclude:
  - RUBY: 2.1.8
    RAILS: 5.0.0.beta2

ジョブの設定

Yaml Axisを選択

Yaml matrix execution strategyを選択

全く同様の結果が得られます

最初の例と違って動的に変化する値はリポジトリ内のymlから参照するため「パラメータを追加したい時に複数のジョブに設定を反映させる必要がある」という問題は解決しています。

また、除外設定もymlを利用するのでワンライナーのGroovy式よりは見やすいかと思います。

その他詳しいことはGitHub か wiki を御覧ください。

Jenkinsでマトリックステストをガリガリやってる人は是非Yaml Axis Pluginをご利用ください！

*1:Groovy式がtrueで評価された時のみ実行

Gitlab Merge Request Builder Pluginをv2.0.0に上げる場合には注意が必要

忙しい人のためのまとめ

v1とv2で設定ファイルに互換性がないので注意すべし

経緯

この辺

GitLab Merge Request Builder plugin さん、v1.2.4からv2.0.0にアップデートしたのにリリースノート皆無かよ。。。

— sue445 (@sue445) January 3, 2016

https://t.co/4rcTTHjlb8 のPRをななめ読みしてアップデートしたら設定吹っ飛んだ。。。設定ファイルをdailyでバックアップとっておいて正解だった

— sue445 (@sue445) January 3, 2016

早く寝るつもりだったが怒り駆動でissue投げるに至った https://t.co/a21g6BEHO8

— sue445 (@sue445) January 3, 2016

本家にissue投げたんですが中の人からの反応はありません。

github.com

本家から回答出てからブログを公開しようと思ったけどなかなか反応がないので先にブログを公開します

僕がissue投げた後に中の人がコミットをpushしてるから気づいてないはずないんだけどなぁ。。。

v1とv2で設定の互換性がない理由

上記issueにも書いてますが、インスタンス変数をリネームしてるのが原因です

https://github.com/timols/jenkins-gitlab-merge-request-builder-plugin/commit/7db92291400d6b0d94f29f6ccd1b63ddbae32b62#diff-2a2ae89bc4c1579a77be4e4d68f9fdb1L34

本人は軽いリファクタリングのつもりで _projectPath を projectPath にリネームしてるんだろうけど、Jenkinsはインスタンス変数を全部シリアライズしてxmlファイルで保存してるので、何も考えずにインスタンス変数を変えたりしたらプラグインアップデート直後に設定が全部吹っ飛びます(;´Д｀)

やるのはいいんだけどせめてどっかに注意書きくらい書いてほしかった、というのが上記issueです。

あ、1系からアップデートせずにv2.0.0を新規にインストールする分には全く問題ないです

アップデート方法

アップデート前には Jenkins backup script でバックアップをとるなり、 JobConfigHistory Plugin から人力で設定を復旧する必要があります

v2.0.0の目玉機能

v2.0.0はcommit status APIに対応してるのでMR上にJenkinsのビルドの状態が出るという素晴らしい機能があるので使ってる人は早くアップデートした方がいいです

Jenkins Yaml Axis Pluginを作った

正月休みから作ってたやつが完成したので公開しました

Jenkins Yaml Axis Pluginについて

Yaml Axis Plugin - Jenkins - Jenkins Wiki

github.com

Travis CIみたいにyamlファイルからマトリックステストの軸を作成するためのプラグインです

使い方

1. リポジトリにyamlファイルをコミット

# axis.yml
RUBY_VERSION:
  - 2.1.8
  - 2.2.4
  - 2.3.0

DATABASE:
  - mysql
  - postgres
  - oracle

2. 軸を設定でyamlファイルとkeyを設定する

面倒かもしれないですが1つずつファイル設定してください （matrix project pluginのソースを読んだけど一箇所で複数の軸を設定するのは無理っぽかった）

3. 実際にビルドするとyamlの値で軸が作られる

今までJenkinsだとマトリクステストの組み合わせの設定をリポジトリに含めることができなかったですが、Yaml Axis Pluginを使うと設定をリポジトリに含めることができるようになるので是非お使いください。

その他

今回初めてGroovy と GradleでJenkinsプラグインを作った

プラダクトコードにもJavaは使ってないですｗ

通常Jenkinsプラグインを作る時はmavenなのですが、gradle jpi pluginを使えばmaven使わずにgradleでプラグインの公開までできます

github.com

Gradle JPI Plugin - Jenkins - Jenkins Wiki

ハマりどころとしては、groovyとgradleがそれぞれ古いバージョンに依存しているため最新のものが使えないということです

groovyはJenkinsにバンドルされているバージョンしか使えない (v1.8.9)

• 2系でもプラグインのビルドはできるんですが、Jenkinsにマウントした時にエラーになることがある。
• 今回の場合、スーパークラスのコンストラクタを呼びだそうとした時に「コンストラクタの数が一致しない」的な実行時エラーが出て、Groovyのバージョン違いが原因だと気づくのに2日くらいかかりました。。。*1
• あと1.8だと withCloseable が使えないのが厳しい

gradle jpi pluginがgradle 2.3でしか動かない模様

• 2.10を使ったら gradle jpi でStackOverflowErrorがおきた
• CHANGELOG を見ると「fixed StackOverflowError when using Gradle 2.8」って書いてあるので治ってはいそうなんですが、2.8でも同じエラーが起きたので2.3使うのが確実っぽい

このように最新バージョンが使えないのは厳しいところですが、素のJavaやMaven使うのに比べたらかなり楽でした

Groovy最高！！！！Gradle最高！！！！

プラグインの公開申請方法が変わってた

以前まではJenkinsプラグインを公開（githubのjenkinsci organizationへのforkやcloudbeesの設定）する時はメーリングリストでの依頼だったのですが、Jiraでチケットを上げるようになってました*2

https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Requesthosting

僕のチケットはこんな感じ（Jiraはログインしないと見れないのでスクショ貼ります）

*1:ユニットテストだと問題なかったので、テストとJenkinsで使われてるgroovyのバージョンが違うんだろうなぁということで原因判明

*2:メーリングリストのプラグイン公開依頼が2ヶ月前くらいから止まっていたので調べたらJiraに移行してたのが分かった

Jenkins GitLab Logo Plugin をリリースしました

リフレッシュ休暇中にJenkinsプラグインを作ってました。 なにげに初Jenkinsプラグイン公開です*1

github.com

GitLab Logo Plugin - Jenkins - Jenkins Wiki

JenkinsのダッシュボードにGitLabのプロジェクトに設定されているアイコンを表示するためのプラグインです。

元々は社内版魔改造GitLab用で作ってたのですが公式でサポートされたのでプラグインもOSSにしてUpdate siteに登録しました

Jenkinsプラグイン公開時に役に立ったリンク

この辺

• Jenkinsプラグインを公開する - Qiita
• Jenkins Pluginを作成してみた。 - Qiita

実際のMLでのやりとりは https://groups.google.com/forum/#!topic/jenkinsci-ja/XLCz4ZbTUTA 。日本語でOKなのがよい

リリース時のコマンド

mvn release:prepare release:perform

ダメだったらこっち

mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare org.apache.maven.plugins:maven-release-plugin:2.5:perform 

参照：https://groups.google.com/forum/#!topic/jenkinsci-ja/kbhtt_pHHSg

頑張ったこと

• Spock でテストコードを書きつつ、GitLabのAPIに通信する部分は Betamax でスタブにしています
  • https://github.com/jenkinsci/gitlab-logo-plugin/blob/gitlab-logo-1.0.0/src/test/groovy/org/jenkinsci/plugins/gitlablogo/api/GitlabApiSpec.groovy

*1:ChatWork Plugin は前任者から引き継いだので自分のオリジナルじゃない