ラベル Jenkins の投稿を表示しています。 すべての投稿を表示
ラベル Jenkins の投稿を表示しています。 すべての投稿を表示

2022年6月24日金曜日

Jenkinsfile の checkout gitSCM で LFS Pull のタイムアウト設定

【Jenkins】ERROR: Timeout after 10 minutes - コガネブログ

hudson.plugins.git.GitException: Command "git lfs pull origin" returned status code 143:

ゲーム開発してると git lfs においてるファイルが大きくなりがちで、タイムアウトで取得失敗することもあるかと思います。
そういう場合は↑のブログにある通り、チェックアウトのタイムアウトを延ばせば解決します。
これは git lfs pull が checkout の拡張として実装されているからです。
https://javadoc.jenkins.io/plugin/git/hudson/plugins/git/extensions/impl/GitLFSPull.html

Jenkinsfile の場合は以下のようにします。
CloneOption にも timeout 設定がありますが、これはその名の通り clone するときのタイムアウトなので git lfs pull には効果ありません。

checkout(
    scm: [$class: 'GitSCM',
        extensions: [
            [$class: 'GitLFSPull'],
            [$class: 'CheckoutOption', timeout: 30],
            [$class: 'CloneOption',
                timeout: 30,
            ],
            ...
        ],
    ]
)

大分前に調べたのですが、すっかり忘れてたので備忘録として残しておきました。

投稿者 時刻: 0 件のコメント:
ラベル: ,

2022年6月7日火曜日

Jenkinsfile の sh ブロックの shellcheck をする GitHub Action をリリースしました

https://github.com/srz-zumix/jenkinsfile-shellcheck

actionlint が run の内容に対して shellcheck してくれるのをみて、Jenkinsfile の sh にもしてほしいなと思って作ってみました。

一応それっぽくできたのですが、何点か既知の問題があります。

sh ブロックの検出は AstBuilder 使ってるので問題ないのですが、行継続のエスケープが展開されて一行になるので、行番号がズレてしまうのが問題です。

ちなみに上は Groovy の文字列の記述がどう展開されるかテストしたものです。
Groovy の文字列記述には複数種類があります。ダブルクオーテーション・シングルクォーテーション、それを３つつなげて複数行記述。「$/」と「/$」で囲うことでも複数行記述できます。このうちシングルクォーテーション以外は GString にあたります。（$/~/$はエスケープがそのまんま展開されるのがダブルクオーテーションと異なります）

GString は「${HOGE}」のような変数を展開します。
Jenkinsfile で GString の場合に環境変数を参照する場合に ${env.HOGE} のように書くこともあるのではないでしょうか。
（GString は知らないと結構ハマりやすいところだと思います）

AstNode から getText すると GString は展開されて取得できるのですが、そのとき「${env.HOGE}」は「env.HOGE」として展開されます。
この挙動はそんなには問題ないですが、Jenkinsfile が実行されるときのそれとは異なるので注意。


実行時と異なるという点での問題はまだあります。
sh の引数には単一の文字列ではなく、文字列連結して渡すことも当然できるため以下のようなケースで正しく解析できません。

頑張ればできないことはないかもしれませんが、今は非対応です。

ちなみに GString でシークレット環境変数を使うと展開されてから評価されるので shell 実行時に環境変数展開されるようにすべきなのですが、その警告は Jenkins がしてくれるので jenkinsfile-shellcheck ではノータッチです。
（ジョブ実行時もしくは validate で検出可能）

issue や pull request お気軽にどうぞ。
では、今回は以上です。

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2022年4月26日火曜日

Jenkinsfile がでかすぎてエラーになる場合の対処方法

 Jenkinsfile に記述してる処理が多すぎて以下の例外が発生してしましました。

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Method code too large!

java.lang.RuntimeException: Method code too large!
	at groovyjarjarasm.asm.MethodWriter.a(Unknown Source)
	at groovyjarjarasm.asm.ClassWriter.toByteArray(Unknown Source)
	at org.codehaus.groovy.control.CompilationUnit$17.call(CompilationUnit.java:827)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:142)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:127)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:571)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:523)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:337)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)

これは Groovy (Java) の 64kb 上限にかかったために発生した Exception です。
https://stackoverflow.com/questions/40049917/jenkins-pipeline-script-fails-with-general-error-during-class-generation-metho
method のサイズが大きすぎるのが問題なので、pipeline 以下に直接記載されている処理を別 method に切り出して、pipeline からは呼び出すだけにしたりしてサイズを削減してみてください。
SharedLibrary に切り出してもいいですし、ジョブを分ける方法もあると思います。

なんにせよ分割することで対応することになると思います。
今回は以上。では。

投稿者 時刻: 0 件のコメント:
ラベル: ,

2022年3月24日木曜日

GitHub Actions だけで Jenkinsfile の lint をする

 皆さん、 Jenkins 使ってますか？
私は仕事で使ってます。最近は GitHub Actions が使えるようになったので、脱 Jenkins を進めているのですが、まだまだ Jenkins とのお付き合いは続きそうな感じです。

ところで近年の Jenkins に久しぶりに触れているのですが、昔と大分変わってきた印象があります。
そのなかでも私は as Code に注力をしていっています。
Jenkinsfile を使ったジョブの定義は当然のことですが、JCasC (Jenkins Configuration as Code) を使った Jenkins そのものの as Code をしています。あとは JobDSL も使ってます。（もう GUI でぽちぽちしてジョブ作るのがしんどいなと思うようになってしまった）JCasC も JobDSL も便利なんでぜひ使ってほしいところですが、今回は Jenkinsfile の話です。

パイプラインの Validate

as Code をすると PR 出してレビューしてもらって、履歴も管理しやすいしとっても便利です。
さて、PR を出したとき Jenkinsfile の動作確認はどのようにしていますか？
もちろん「PR ブランチを指定してジョブを実行する」これでもいいです。
しかし、カッコの閉じ忘れだったり、しょうもない typo で時間を無駄にしてしまうことはないでしょうか？

そういうときは jflint が便利です。
「Jenkins 2.0 (5): Jenkinsfileをコマンドラインからlintする - 生産性向上ブログ」
Jenkins にはパイプラインの Validate してくれる API が備わっていますが、jflint はその呼出を簡単にできるようにしてくれたものです。（できれば公式の jenkins-cli.jar が対応してほしい）
jflint 自体は Jenkins の API を実行しているだけなので、Jenkins のインスタンスが必要になります。
通常は使っている Jenkins のインスタンスを挿せば問題ないです。
というか、そうでないと利用しているプラグインがインストールされていなくて Validate が失敗したりしてしまいます。

さて、ここで表題に戻ります。
「GitHub Actions だけで Jenkinsfile の lint をする」
jflint を使った方法は Jenkins のインスタンスが必要ですが、ここでは利用している Jenkins には到達できない、もしくは汎用的・テンプレート的なリポジトリで対になる Jenkins インスタンスが存在しないと過程して GitHub Actions のみで lint します。
（※Jenkins インスタンスがあって到達可能ならそれ使ったほうがいいです）

GitHub Actions に Jenkins を起動する

GtiHub Actions ではサービスコンテナの機能があります。
テストするために DB など他のサービスがほしい場合に便利な機能です。

これを利用して Jenkins を起動し、サービスコンテナの Jenkins に Validate してもらいます。（Jenkins は使いますが GitHub Actions だけで完結します。Jenkins 使わずに Validate するのは相当しんどい。プラグインがあるしカバーしきれない…）

サービスコンテナは↓な感じで起動できます。
セットアップウィザードを無効にしないと入力待ちで止まってしまうので、このオプションは必須です。
起動したコンテナのIDは「job.services.サービス名.id」で取れるのでこれを使って steps などで操作することもできます。

    services:
      jenkins:
        image: jenkins/jenkins:lts-jdk11
        credentials:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
        env:
          # セットアップウィザードを無効
          # disable setup wizard
          JAVA_OPTS: -Djenkins.install.runSetupWizard=false
        ports:
          - 8080:8080
          - 50000:50000

上記例では起動したコンテナに localhost:8080 でアクセスできるので、この URL で jflint を実行すると Jenkinsfile の lint が GitHub Actions だけでできるようになります。（※これだけじゃならない）

プラグインをインストールする

さて、ここで１つ問題が発生します。起動した Jenkins はプラグインが空っぽで Validate すらできない状態になってしまっています。

デフォルトプラグイン、推奨プラグインをインストールする必要があります。
さらに、Validate する Jenkinsfile によっては追加でプラグインのインストールが必要です。
プラグインのインストールは jenkins-cli.jar の install-plugin で可能なので、これをサービスコンテナの Jenkins に対して実行すればインストールできます。

java -jar jenkins-cli.jar install-plugin -s http://localhost:8080 ws-cleanup

こんな感じですね。サービスコンテナから jenkins-cli.jar をダウンロードして実行するか、コンテナに対して exec すればできると思います。

setup-service-jenkins アクション

さて、GitHub Actions で Jenkins を起動して jflint することができそうなことはわかりました。しかし、プラグインのインストールが必要でちょっとめんどくさいです。
なので、アクションにしてみました。

https://github.com/srz-zumix/setup-service-jenkins

サービスコンテナの記述はそれぞれ必要になりますが、コンテナ ID を指定してこのアクションを実行すると必要なプラグインを Jenkins にインストールするのと、 jenkins-cli のラッパースクリプトを agent にインストールします。

      - uses: srz-zumix/setup-service-jenkins@main
        with:
          id: "${{ job.services.jenkins.id }}" # サービスコンテナの ID （job.services.サービス名.id）
          port: 8080 # ポート番号（サービスコンテナのポート設定と合わせる）
          install_suggested_plugins: true # Suggested Plugins をインストールするかどうか
          plugins_file: JenkinsPlugins.txt # 追加でインストールしたいプラグインのリストファイル
公式イメージからのセットアップ

例えば公式のイメージを起動した場合はプラグインが空っぽなので、install_suggested_plugins オプションを true にしてデフォルト推奨プラグインをインストールするか、プラグインが列挙されたファイルを plugins_file に指定してインストールしてください。
デフォルト推奨プラグインはこちらのファイルに列挙したものになっています。
（Suggested Plugins をインストールした状態から cli でダンプ、加工したもの）
https://github.com/srz-zumix/setup-service-jenkins/blob/main/resources/DefaultJenkinsPlugins.txt

公式イメージを使う場合はセットアップウィザードを無効にすることを忘れないでください。
現状アクション側で対応してないので、冒頭に書いたようにサービスコンテナを起動するときのオプションが必須です。

カスタムイメージからのセットアップ

例えば、実際に使用している Jenkins のベースイメージがあり、プラグインなどセットアップ済みであれば特にプラグインのインストールは不要になると思います。
おそらく公式イメージよりも都合がよいと思うのでこちらのほうがおすすめですが、クリーンな状態からテストしたい場合などは公式イメージを使うほうがおすすめです。
適宜選択してください。

jenkins-cli.jar のラッパースクリプト

このアクションを使用すると agent マシンにラッパースクリプトの jenkins-cli をインストールします。こちらはサービスコンテナの Jenkins を挿すようにしただけのラッパーです。
CLI でそこそこ自由に Jenkins を操作できるのでワークフローを作る際に使ってみてください。

GitHub Actions だけで Jenkinsfile の lint をする

最終的にできあがったワークフローはこちらです。
https://github.com/srz-zumix/github-actions-sample/blob/main/.github/workflows/reviewdog-jflint.yml

公式イメージ + suggested plugins だと ansiColor プラグインがインストールされないので、jflint で指摘されているのがわかりますね。

今後の展望

サービスコンテナで Jenkins が起動し、プラグインインストールや CLI での操作が可能になりました。今後は JCasC をロードさせて Jenkins の設定を読み込ませた状態でジョブやスクリプトを実行してみたいです。
また、Shared Library のテストが書け、実行できると思っているのでそのへんも手を付けたいです。

以上。


投稿者 時刻: 0 件のコメント:
ラベル: , ,

2021年10月29日金曜日

Docker な Jenkins でプラグインインストール済みイメージを作る

 表題の件は検索すればすぐ見つかる内容ですが、古い方法のほうが検索上位に来ることが多いのでこの記事を書きました。

旧方式（install-plugins.sh）

プラグイン名や、プラグインが列挙されたテキストファイルを渡すとインストールしてくれる shell スクリプトが Jenkins のベースイメージに入っているのでそれを使います。

COPY JenkinsPlugins.txt plugins.txt
RUN /usr/local/bin/install-plugins.sh < plugins.txt

plugins.txt の中身は以下のように「プラグイン名:バージョン」となっています。

analysis-model-api:10.3.0
ansicolor:1.0.0
antisamy-markup-formatter:2.1
apache-httpcomponents-client-4-api:4.5.13-1.0
authentication-tokens:1.4
authorize-project:1.4.0
badge:1.8

この方法は既に Deprecated です。
https://github.com/jenkinsci/docker/blob/master/README.md#install-plugins-script-deprecated

一部プラグインがインストールできないなくて、調べたことがきっかけで新方式を知りました。
実際にはツールの問題じゃなく、lts イメージを使ってたのが直接の原因でしたが。
Some plugins failed to download! Not downloaded とエラーになる場合は、lts-jdk11 のイメージを使いましょう。

新方式（jenkins-plugin-cli）

新しい方法は CLI を使います。CLI を使って操作するのが現在の主流のようです。
https://github.com/jenkinsci/docker/blob/master/README.md#plugin-installation-manager-cli
この CLI はベースイメージに入っているので追加インストールとかは不要です。

COPY JenkinsPlugins.txt plugins.txt
RUN jenkins-plugin-cli --plugin-file plugins.txt

plugins.txt の中身は install-plugins.sh のときと同じで大丈夫です。
プラグイン列挙ファイルを渡す場合は --plugin-file(-f) を使います。
オプションの詳細は README を参照してください。
https://github.com/jenkinsci/plugin-installation-manager-tool#cli-options

インストールされているプラグインリストを取得するには以下のようにすれば可能なので、イメージを起動後に手動でプラグインをインストール後、docker exec とかでコンテナに入ってコマンドを実行してください。

$ jenkins-plugin-cli --list

Installed plugins:
ace-editor 1.1
analysis-model-api 10.3.0
ansicolor 1.0.0
antisamy-markup-formatter 2.1
apache-httpcomponents-client-4-api 4.5.13-1.0
authentication-tokens 1.4
authorize-project 1.4.0
.
.
.
workflow-job 2.41
workflow-multibranch 2.24
workflow-scm-step 2.13
workflow-step-api 2.24
workflow-support 3.8
ws-cleanup 0.39

Bundled plugins:

All requested plugins:

Plugins that will be downloaded:

Resulting plugin list:
ace-editor 1.1
analysis-model-api 10.3.0
ansicolor 1.0.0
antisamy-markup-formatter 2.1
apache-httpcomponents-client-4-api 4.5.13-1.0
authentication-tokens 1.4
authorize-project 1.4.0
.
.
.
workflow-job 2.41
workflow-multibranch 2.24
workflow-scm-step 2.13
workflow-step-api 2.24
workflow-support 3.8
ws-cleanup 0.39
Done

ただ、この出力をそのまま --plugin-file として渡せないのでスクリプトコンソールで出力したほうが手っ取り早いかもしれません。
その場合は下記のようなスクリプトを実行することになると思います。

def plugins = jenkins.model.Jenkins.instance.getPluginManager().getPlugins()
plugins.each {
    println ("${it.getShortName()}:${it.getVersion()}")
}
最後に

今回はプラグインの事前インストールでしたが、Jenkins の Docker イメージ使ってちょっとやってみたいことがあるので進展がありましたら、またブログにしたいと思います。
では。

投稿者 時刻: 0 件のコメント:
ラベル:

2021年10月22日金曜日

npm-groovy-lint + reviewdog で Jenkins Shared Library の PR チェック

 reviewdog は様々なツールの出力から PR に対してレビューをつけてくれるとても便利なツールです。私も GitHub Actions で reviewdog 使って shellcheck とか lint とかをよくかけています。

今回は Jenkins Shared Library の groovy スクリプトの lint をしたいと思い、npm-groovy-lint + reviewdog の GitHub Actions を用意したので紹介します。

reviewdog とツールがセットになったアクションがたくさんありますが、
npm-groovy-lint のアクションはなかったので作るか、アクション側で書くかのどちらかになります。
今回はアクション側で対応したいと思います。

.reviewdog.yml

reviewdog は .reviewdog.yml に runner 情報（実行コマンドや出力フォーマット）を書いておくと、-runners オプション指定で簡単に実行できるようになるので、その方法を使います。

作成した .reviewdog.yml がこちらです。

runner:
  npm-groovy-lint:
    # cmd: npm-groovy-lint # (required)
    cmd: npm-groovy-lint -o log.txt && cat log.txt
    errorformat: # (optional if you use `format`)
      - '%-P%f'
      - '%*\s%l%*\s%tnfo%*\s%m'
      - '%*\s%l%*\s%tarning%*\s%m'
      - '%*\s%l%*\s%trror%*\s%m'
      - '%-Q'

コマンド指定のところで一度ログファイルに出力しているのは、色付き出力されたものを reviewdog に認識させるのが面倒だったためです。

github/workflows/reviewdog.yml

続いて、GitHub Actions のワークフローです。
こちらは npm-groovy-lint を実行する環境を整えつつ、reviewdog を実行するワークフローになっています。

name: GitHub Actions - reviewdog
on:
  pull_request:

jobs:
  groovylint:
    runs-on: ubuntu-latest
    container:
      image: docker://nvuillam/npm-groovy-lint
      credentials:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_TOKEN }}
    steps:
      - run: apk add curl git
      - uses: reviewdog/action-setup@v1
      - uses: actions/checkout@v2
      - name: Run reviewdog
        env:
          REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          reviewdog -reporter=github-pr-review -runners=npm-groovy-lint

npm-groovy-lint を実行するのに、公式のコンテナ上で実行するのが楽だったのでそのようになっています。このコンテナには reviewdog が実行するために必要になる curl と git が入ってなかったので、はじめに追加をしてます。

結果

これでセットアップ完了です。
以下のように npm-groovy-lint の結果をレビューコメントしてくれるようになりました。



投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2018年11月26日月曜日

[Jenkins] 種類ごとにジョブをリストアップ

参照：
https://support.cloudbees.com/hc/en-us/articles/226941767-Groovy-to-list-all-jobs

下記をスクリプトコンソールで実行しましょう。

ジョブのクラス名付きでリストアップ
def list = Jenkins.instance.getAllItems(Job.class)
list.each{ 
  println it.name + " - " + it.class
}
return list.size()

目的のクラスでリストアップ
def list = Jenkins.instance.getAllItems(class hudson.model.FreeStyleProject)
list.each{ 
  println it.name
}
return list.size()
投稿者 時刻: 0 件のコメント:
ラベル:

2018年9月18日火曜日

[Jenkins] GroovyPostbuildAction.createShortText が使えなくなりました 

import org.jvnet.hudson.plugins.groovypostbuild.*;
build.getActions().add(GroovyPostbuildAction.createShortText(text));

Groovy Postbuild Plugin のバッジ処理が Badge Plugin に切り出されたので、Badge Plugin を使うようにしましょう。

import com.jenkinsci.plugins.badge.action.*;
build.getActions().add(BadgeAction.createShortText(text));

ちなみに import するパスは、src/main/java 以下を書く感じなので覚えておきましょう。
（最初プラグイン名だけ変えて、うまくいかなくてうんうん言ってた…）
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年11月22日水曜日

CloudBees Jenkins Advisor をインストールしてみた


「第11回 Jenkins勉強会」で知った CloudBees Jenkins Advisor をインストールしてみました。
勉強会参加報告はこちら→（ブログズミ: 「第11回 Jenkins勉強会」に参加してきました）



SignUp してインストール
「USE IT FREE NOW!」からサインナップします。


完了すると以下のような画面になります。
（Trial Period Overなのは、むかーし使ってたことがあるから。前と大分変わりましたね）


以前に登録していたので SignUp 手順が確認できませんでしたが、必要になってくるのはアカウント名とパスワードなので、それがあれば問題ありません。


プラグインインストール
プラグインのインストールは普通に Jenkins のプラグイン管理からできます。
「CloudBees Jenkins Advisor Plugin」があるので、いつもどおりインストールしましょう。



セットアップ
「Jenkins の管理」を開くと以下のようなメッセージが出ています。「Connect Now」をクリックしましょう。


接続設定画面が開くので、先程登録した「CloudBees」のアカウントメールアドレスとパスワードを入力します。
「Advanced configuration」がありますが、とりあえず使いたいだけなので特に設定せずに「Connect account」します。


すると、アカウントメールアドレスに以下のようなメールが来ます。
レポートが１日ごとに来るようなので、１日待ちましょう。


レポート




なんか出てますね・・・
とりあえず今回はインストールして使ってみただけなので、ゆくゆく調べながら対応していきますか。

最後に
Jenkins Advisor についてはこちらの CloudBees のブログにも書かれています。
Jenkins AdvisorでJenkinsのダウンタイムを防ぐ | Cloudbees Jenkins Solutions
ロードマップによれば、閉じられた環境の Jenkins の診断対応やダッシュボードの追加がされるようです。
こちらにも期待しつつ、インストールした状態でしばらく使ってみようと思います。

では。



投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年11月13日月曜日

「第11回 Jenkins勉強会」に参加してきました

どうも僕です。仕事が始まって１週間。こちらでの生活にも慣れてきました。
そんなこんなで「第11回 Jenkins勉強会」に参加してきました。
東京来て一発目の勉強会！久しぶりの参加報告って感じですね。

今回の講演は３つ + LT ３本立て。
「初めての自動テスト meets Jenkins」


最初は「初めての自動テスト ―Webシステムのための自動テスト基礎」を翻訳された玉川紘子（@nkns165）さんの講演。

原著者がアジャイルサムライを書いた人と一緒とか、CI の章がないが CI があっての自動テスト（あるの当たり前）とか、翻訳こぼれ話とか、興味深い話が聞けました。
自分も本に関わってみたいなぁー



「Jenkins World 2017 の報告」
2つ目は Jenkins World 2017 で「Most Valuable Advocate」受賞の中村知成（@ikikko） さん！
（そのへんは @ikikko さんのブログへ）



Jenkins Advisor はじめて知りました。さっそく使ってみようと思いました。

Jenkins world の動画はここかな？
https://www.youtube.com/user/CloudBeesTV


「Jenkins PipelineとBlue Oceanによる、フルスクラッチからの継続的デリバリ」
最後は川口さん！

↓は今回の講演と（たぶん）同じヤツ




#はい

when で任意ブランチでのみ stage できるっぽいので、iutest のパッケージビルドを Jenkinsfile にお引っ越ししようと思いました。

LT
ここから LT
遠くの"計画"よりも今日の"CD"(継続的デプロイ)


タミヤ カムプログラムロボット工作セットで作るXFD


開発者(個人)のためのJenkins 運用編


感想
参考になる話、知見、情報と持ち帰るものが予想以上にあってよかった。
LT はホントいつも面白いし、すごい！
懇親会でも色々いいお話聞けたのでとっても大満足。

最後に、テクマトリックスさん、スタッフのみなさん、そして講演者の方々、ありがとうございました～

投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年9月25日月曜日

[備忘録] Jenkinsfile 作成時に約に立ちそうなリンクまとめ

はじめに
最近、Jenkinsfile を書く機会ができて、実用での Jenkinsfile を書くことになったら、全然知らないこと・わかってないことが多くて調べたときのリンクをざっと貼り付けてみました。
このブログを読んでいただいている方でも、もしかしたら、参考になることがあるかも？
では、並べていきます。

自分用リンクまとめ

Pipeline Steps Reference
各ステップのリファレンス。
基本的な使い方はここに書いてある。

workflow-support javadoc
困ったときは javadoc 見る。
リンク先は workflow-support のものなので、知りたいオブジェクトを println でもして、クラス名でぐぐったらだどりつけると思う。

Groovy でプロパティ一覧とメソッド一覧を取得する - blog.scheakur.com
javadoc 見なくても、プロパティやメソッドを println しちゃえば何があるか直ぐわかる。

Jenkins2のPipelineを使うときのいくつかのポイント(2016/12/10現在) - Qiita
フリースタイルジョブを build job で呼び出したときに、そのジョブの結果を知りたい場合は build job: 'hoge' , propagate: false

Jenkinsfile を書く前に知っておくべきこと (セキュリティ制約編) - あらしおブログ
Sandbox とかの話。




なんとかなりませんかね？



Jenkinsfile を書く前に知っておくべきこと (機能制約編) - あらしおブログ
"CPS 変換" というものがあるらしく、対応していないコードを書くと UnsupportedOperatinException 例外が送出される。
また、Serializable 非対応なクラスも使えないらしく、以下のように例外になる。
java.io.NotSerializableException: java.util.regex.Matcher

リンク先に書いてあるとおり、@NonCPS なメソッドに括り出すことで対応可能。

Jenkins2.0のPipeline活用法(4月現在) | enish engineering blog
NonCPS についての知見が書いてあります。

Jenkins 2.0 (5): Jenkinsfileをコマンドラインからlintする

jflint 最高です！ありがとうございます！！


リンク
2017/11/08 追加

pipeline スクリプトのサンプル
https://github.com/jenkinsci/pipeline-examples
pipeline 自体のユニットテストフレームワーク（まだ使ったことない。個人的備忘録）
https://github.com/jenkinsci/JenkinsPipelineUnit

最後に
1ヶ月以上ブログ更新が滞ってしまいましたが、次もまだ未定でございますm(__)m
もう少し落ち着いたら、平常運転に戻していきたいなーと思ってます。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年7月18日火曜日

[Jenkins] Pipeline Script からプラグイン機能を呼び出す

ブログズミ: [Jenkins] Groovy で IRC Plugin を使い倒す
以前、Groovy post build プラグインから IRC Plugin の機能を呼び出して、任意のメッセージを飛ばすことをやりましたが、これを Jenkinsfile に記述します。

やり方は単純
Jenkinsfile にそのまま書くだけです。

以前、Groovy Label Assignment plugin 向けに書いた groovy がこちら。
def jenkins = hudson.model.Hudson.instance
def irc_channel="#kiwiirc-iutest"
def p = jenkins.getPlugin("ircbot")
if( p == null ) {
  println("require IRC Plugin")
  return
}
def c = p.imPlugin.provider.currentConnection()
if( c == null ) {
  println("IRC connection not found. please set to IRC configuration")
  return
}
c.send(irc_channel, "label assignment")
return

これを、すこし汎用的にして Jenkins ファイルに追加します。

def send_irc(channel, message)
{
    def jenkins = hudson.model.Hudson.instance
    def p = jenkins.getPlugin("ircbot")
    if( p == null ) {
      println("require IRC Plugin")
      return
    }
    def c = p.imPlugin.provider.currentConnection()
    if( c == null ) {
      println("IRC connection not found. please set to IRC configuration")
      return
    }
    c.send(channel, message)
    return
}

で、あとはお好きなタイミングで呼び出すだけです。
stage('irc-send') {
        send_irc('#TEST', 'ビルドに成功したよ！')
    }


簡単ですね^^
投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年2月21日火曜日

[雑記][Jenkins] Cppcheck Plugin のパイプライン対応がもうすぐ来そうな予感

こんにちは。
先日某所であった勉強会（？）で Jenkins おじさんたちと Jenkins なお話を久しぶりにしたので、滞ってた自宅 Jenkins のパイプライン化対応を再開しようかなと思ってます。

で、Cppcheck のパイプライン対応しようと思ったら、まだ対応してなくて保留していたのも思い出しました。

プラグインの対応状況
Plugin Compatibility with Pipeline : https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md
こちらに主要な？プラグインの対応状況が載っています。
画像は2016年9月のときのものですが、現在もまだチェックがありませんでした。


しかし、issue を見てみると、もうすぐ更新ありそうな気配がしてました。
[JENKINS-35096] Add support for Jenkins Pipeline to the cppcheck-plugin - Jenkins JIRA

早く使えるようになってほしいですね！

※ 実は対応してないプラグインを頑張って使う方法を調べようとしてたんですが、https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md を今見たらほぼほぼ対応してるっぽいので、待ちスタンスに切り替えました。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2017年2月6日月曜日

[Jenkins]「ビルド手順の追加」にある処理を「ビルド後の処理」で実行したい場合の回避策


そっちにあるけど、こっちはない！！ってやつです。

まずやること
  1. 同じような Issue がないか探します。(https://issues.jenkins-ci.org/)
  2. 同じような Issue があったら vote します。
  3. 対応してもらえるのを待ちます祈ります。（￣人￣）



















待てるかっ


Promoted Builds Plugin を使う
Promoted Builds Plugin を使ってこの問題を回避したいと思います。

Promoted Builds Plugin は本来は「ビルドを昇格させる」のに使います。
例えば、デプロイしたら昇格する、下流のテストが全部 PASS したら昇格する、とかですかね。

さて、Promoted Builds Plugin では Promote build が実行されるトリガーに「ジョブのビルド完了後」があります。
つまり、ビルド後の処理的な感じで実行できるのです。
「Promote builds when...」にチェックを入れ、「Criteria」の「Promote immediately once the build is complete」にチェックを入れます。（unstable でも実行したい場合は「Trigger even if the build is unstable」にもチェック）


そして、「Actions」には「ビルド手順」「ビルド後の処理」の中からアクションを選択できます。


ということで、「ジョブのビルド」→「ビルド完了」→「昇格ビルド」→「ビルド手順の処理」という流れで、「ビルド手順」にしかない処理も「ビルド後」にできちゃうのです！！

昇格成功すると★がつきます。


Post Build Script Plugin を使う
もっと直球に解決してくれるプラグインがあります。

それが、Post Build Script Plugin です。
名前からすると、「ビルド後の処理」で「スクリプト」を実行できるようなプラグインの印象を受けますが、このプラグインで実行できるのは bat/shell スクリプト、Groovy スクリプトだけでなく、「ビルド手順（build step）」の処理も実行できちゃうのです！！

Post Build Script Plugin をインストールすると「ビルド後の処理」に「Execute a set of scripts」が追加されるので、それを追加してください。


まさに、これ！！なプラグインですね。
最初は Promoted でできるよなーと思って調べ始めたのですが、こんな便利なプラグインがあったとは…
今後、Jenkins 構築するときには積極的にインストールしておきたいプラグインの１つになりそうです。


最後に
いかがでしたでしょうか？やっぱり探せばあるもんですね。
Jenkins ネタはまだまだ尽きないですな。

ではでは～




投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年1月23日月曜日

[Jenkins] オフライン理由にリンクを貼れなくなって困っている

いつ頃からかわからないのですが、Jenkins のスレーブをオフラインにするときの理由にリンクを貼っても、テキストとして表示されるようになってしまってました。
この前の第7回大阪Jenkins勉強会で川口さんに直接聞いてみたら、OWASP Markup Formatter Plugin 入れたら出るはずと教えてもらったのですが、オフライン理由のところはやっぱりダメでした。
実は、OWASP ってデフォルトで入っていたような気がしていて、私の環境でも既にインストール済みでした。


試しに、 OWASP を無効にしてみたところ、ジョブの説明やビルドの説明のところはリンクが無効になったので、プラグインはこれであっていると思うのですが…

どなたか解決方法あればコメントくださいm(__)m
投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年12月15日木曜日

「第８回大阪Jenkins勉強会」で発表してきた

タイトルのとおり、「第８回大阪Jenkins勉強会」で発表してきました。

発表資料はこちら




補足
いやーとっても緊張しました。スライドは結構うまくできたかなーと思ってたのですが、やっぱり１回は話す練習しとかないと言いたいこと言いそびれますね。。。
というわけで、補足。

CI サービスの特徴
質問で特徴について聞かれて、あんまり特徴がない…と答えたものがありましたが、iutest 開発での利用範囲ではあまり特徴に差がないということです。
特にデプロイ関係はノータッチなので、ご了承ください。

Groovy 使えばなんでもデキル
狂ったように Groovy 推ししてましたが、職人技で難解な Jenkins を作ることを推してるわけじゃないです。
なんかあったら Groovy 使って解決できるから大丈夫。という心の余裕を持てるようになって欲しいという点と、（新人・後輩に）全能感を味わってもらうことで Jenkins 仲間に引きずり込もうという考えです。

テーマ
気づいた方もいるかと思いますが、スライドテーマは BlueOcean をイメージして作りました。
スライド自体は reveal.js を使っているのですが、それ用の theme です。
もし使いたい方がいれば、ご自由に使ってください。
github から取ってこれます。

最後に
前回に引き続き、今回も超絶面白勉強会でした。
他の方の発表はどれも、すごいなぁと思ったり、なるほどと思ったり、そしてクソ笑えたり、
いやー濃いですね。


ともあれ、自分はもっとうまく話せるようにならないとダメだなぁと思いました。
来年も挑戦できたらいいなぁ～

というところで、以上。
では、またどこかで。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年9月12日月曜日

[Jenkins] BlueOcean beta 版がプラグイン管理に登場

公開されてました。
https://wiki.jenkins-ci.org/display/JENKINS/Blue+Ocean+Plugin
プラグイン管理からインストールできます。



（スクリーンショットは beta 3 ですが、既に beta 5 がリリースされてます。）

以前、ソースコードからビルドしてインストールする方法を紹介しましたが、
これからは単純にインストールするだけで良さそうです。
ブログズミ: [Jenkins] Blue Ocean を試してみる

投稿者 時刻: 0 件のコメント:
ラベル:

2016年8月22日月曜日

[Jenkins] Warnings Plugin の新規警告の計算について

Warnings Plugin には警告の総数もしくは新規警告数に応じて、ステータスを変更する機能があります。

この機能を使って、警告が残っていたら不安定（黄）にすることが多いのですが、
最近になって、警告が増えたら（新規警告があったら）不安定にするような使い方を始めました。
そうしたらものの見事にハマったので備忘録として書き残しておきます。

新規警告がないにも関わらず不安定になってしまう！！
そんなことが起こってました。
再現ジョブを作ったのでそちらで確認していきます。

まず、ビルドするソースコードはこちら
int main(int argc, char** argv)
{
    return 0;
}
なんのへんてつもないコードです。
これを g++ -Wall -Wextra でビルドするジョブを作成します。

これを1回成功させておきます。
このときの警告は2件です。


続いて、新規警告が1件でもあったら不安定するように設定を変更します。
そして、ソースコードも以下のように書き換えます。
int main(int argc, char** argv)
{
    int x;
    return 0;
}

これを実行すると、結果は新規警告1件により不安定になります。
このとき警告の総数は3件です。


ここまでは、問題ありません。
次が問題です。

もう一度ジョブを実行します。
今度はソースコードを変えてませんので、警告数は3件のままで新規警告も 0件 のはずなので、成功になるはずです。ところが、実際には不安定になってしまうのです。なぜ？！



なぜなのか
ログを見てみましょう。

なぜか新規警告が1件と出力されています。
ビルド結果ページを見ると 0件 なのに？

どうやら、Warnings Plugin で見る新規警告は、最後の成功ビルドから見ての新規警告だったようです。
（ソースコード変更後の警告数は3件なので、成功時の警告2件からみると1件増えたように見える）
ログにもちゃんと
[WARNINGS] Computing warning deltas based on reference build #9
と書いてありました。

前回のビルドから見て欲しい
簡単でした。
「Use previous build as reference」にチェックを入れるだけです。


この状態でもう一度ジョブを実行すると、意図通り成功になりました！


ログもこの通り、ちゃんと１つ前のビルドを参照しているようです。

最後に
「Use previous build as reference」とか、「Only use stable builds as reference」とか、
説明が英語だったのでスルーしてましたが使いどころが分かりました。
また、どういう挙動をしているのか少し分かったことで、通知の仕方の幅が広がりました。
（成功時の警告数を下回るまで不安定するのもアリだと思った）

今回は以上。
では。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年8月9日火曜日

[Jenkins] Pipeline Plugin を使ってみた

Jenkins LTS も2系がリリースされたことですし、そろそろ本格的に移行を始めないとまずいよなーということで構築中です。


まずは、普段一番よく使っている svn のコミットを git にプッシュするジョブを移植しました。
（本当は逆がいいんだけど、そのうち開発フローを見直す予定…）
できたのがこちら。ちょっと詰まったところだけ解説していきます。
node {
    withEnv(['SVN_LOGFILE=..\\svnlog.txt']) {
    stage 'make commit message'
    
    env.SVN_REPO = SVN_REPO
    env.ISSUE_NUMBER = ISSUE_NUMBER
    if( CommitMessage == "" ) {
        bat '''
        for /f "tokens=1,2" %%i in ( \'svn info http://svn.osdn.jp/svnroot/iutest/%SVN_REPO%\' ) do (
          if "%%i" == "Revision:" (
            call :setr %%j
            goto :EOF
          )
        )
        goto :EOF
        :setr
        chcp 65001
        SET LANG=ja_JP.UTF-8
        SET REVISION=%1
        if exist %SVN_LOGFILE% del /F %SVN_LOGFILE%
        for /f "skip=2 eol=- tokens=*" %%c in ('svn log http://svn.osdn.jp/svnroot/iutest/%SVN_REPO% -r HEAD') do (
            @echo %%c >> %SVN_LOGFILE%
        )
        if "x%ISSUE_NUMBER%" == "x" (
            @echo update r%REVISION% >> %SVN_LOGFILE%
        ) else (
            @echo update r%REVISION% #%ISSUE_NUMBER% >> %SVN_LOGFILE%
        )
        '''
    } else {
        env.COMMIT_MESSAGE = CommitMessage
        bat '''
        chcp 65001
        SET LANG=ja_JP.UTF-8
        echo %COMMIT_MESSAGE% > %SVN_LOGFILE%
        '''
    }
    bat '''
    @echo off
    chcp 65001
    SET LANG=ja_JP.UTF-8
    type %SVN_LOGFILE%
    '''

    stage 'git clone'
    deleteDir()
    git branch: 'develop', url: 'git@github.com:srz-zumix/iutest.git'

    stage 'svn export'
    bat 'rm -rf *'
    bat 'svn export --force http://svn.osdn.jp/svnroot/iutest/%SVN_REPO% ./'
    
    stage 'git commit'
    bat 'git add .'
    bat 'git commit -a -F %SVN_LOGFILE%'
    
    stage 'git push'
    //input 'git push OK?'
    bat 'git push git@github.com:srz-zumix/iutest.git develop'
    }
}

どうしたら良いかわからない
Pipeline script をいざ書こうと設定を開いたものの…
どう書けばいいのかサッパリわからない。。。

まず何をしたらいいのか分からない迷子状態です。
第7回大阪Jenkins勉強会の LT を思い返すと、スクリプトを Generate してました。

ということで、Pipeline Syntax を使ってみます。


① Sample Step から「bat: Windows Batch Script」を選んで出てくる ②「Batch Script」にバッチ処理をコピペで③「Generate Groovy」を押すと、スクリプトがに ④ に出てきます。


あれ？これで終わりじゃない？
でも、これじゃあ Pipeline になってないし、こんな感じにしたい！（し、まだ問題がある）

https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin

ということで、次のステップ。
ステージを追加します。

ステージ
ここは詰まってないです。Pipeline Syntax で「stage」を選択して Generate すると
stage 'git push'
こんなスクリプトが出てくるので、コピーするだけ。簡単です。

問題はどうステージに分けるかですが、今回は以下のようにしました。
  1. コミットメッセージの作成
  2. git clone
  3. svn export
  4. git commit
  5. git push

ビルドパラメータを参照する
ビルドパラメータの参照ですが、今までのバッチ処理では環境変数として参照できていたので、Pipeline のバッチ処理でも環境変数で参照できると思ったのですが、そうでもないようです。

node {
    stage 'env'
    bat 'echo %TEXT_PARAM%'
}

このように「ECHO は <ON> です。」と出力されます。


では、どうしたらよいか。
Getting Started with Pipeline
こちらによれば、ビルドパラメーターは Groovy の変数としては見えるようです。

というわけで、以下のように環境変数に set して対応しました。

node {
    stage 'env'
    env.TEXT_PARAM=TEXT_PARAM
    bat 'echo %TEXT_PARAM%'
}

これでビルドパラメーターがバッチ処理から見えるようになりました。

input
動作確認ができるまで、最後の git push ステージに input を入れて push されないようにして検証してました。
これなんですが、第7回大阪Jenkins勉強会のときに川口さんがもっといい方法があるよ～的なことを言っていた気がしたのですが、忘れてしまいました。。。
なんだっけなぁ

最後に
最後に出来上がったパイプラインの実行結果です。


さらに、せっかくなので blueocean で表示。

blueocean についてはこっちを参照してください。
ブログズミ: [Jenkins] Blue Ocean を試してみる


さて、これで Pipeline がどんなものか分かりました。
これからは積極的に使っていこうと思います。
では。


投稿者 時刻: 0 件のコメント:
ラベル:

2016年6月29日水曜日

[Jenkins] Blue Ocean を試してみる

第7回大阪Jenkins勉強会で紹介された Blue Ocean がとっても良さそうだったので、試してみました。
「ブログズミ: 「第7回大阪Jenkins勉強会」に行ってきた」



Blue Ocean は現時点ではまだリリース前ですが、Github にソースコードが上がっており、パッケージをビルドしてインストールすれば使用することができます。
今回はこの方法で Blue Ocean を試してみたいと思います。
（筆者の環境は Windows 10 です。）

Maven
まず、パッケージをビルドするためには Maven が必要になります。
また、Maven を動かすためには JDK も必要になりますので、インストールして JAVA_HOME 環境変数を設定しておいてください。（後述してますが、 JDK は 64bit OS なら 64bit 版をインストールしてください。）

Maven は公式サイトから .zip をダウンロードしてきます。
Maven – Welcome to Apache Maven

ダウンロードしたら、展開し bin フォルダーに PATH を通します。

cmd を起動して mvn --version を実行してバージョンが正しくでればセットアップ完了です。


Blue Ocean をセットアップする
環境の準備ができたら、 github からソース一式を clone します。
git clone https://github.com/jenkinsci/blueocean-plugin.git
(執筆時のコミットは 051caf5aa7c0459abfd78f16d2b68bfb49a5820f)
ルートディレクトリで以下のコマンドを実行。
mvn clean install -DskipTests

途中でダウンロードが止まることがあったので、clean せず再実行
mvn install -DskipTests

それでも失敗する。ぐぬぬ。。。
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.0:install-node-and-npm (install node and npm) on project blueocean-web: Could not download Node.js from: file:/blueocean-plugin/blueocean-web/target/frontend/v5.8.0/win-x86/node.exe: Could not download file:/blueocean-plugin/blueocean-web/target/frontend/v5.8.0/win-x86/node.exe: Source 'blueocean-plugin\blueocean-web\target\frontend\v5.8.0\win-x86\node.exe' does not exist -> [Help 1]

実際にそのフォルダを見に行ってみると、win-x86 フォルダがなく v5.8.0 フォルダの下に node.exe がありました。
JDK が 64bit じゃないとダメなのか？と思って x64 に変更してリトライ。



そこはパスしたものの、今度は別のエラー
[INFO] [20:30:09] error: SyntaxError: blueocean-plugin/blueocean-dashboard/target/jenkins-js-extension.jsx: Bad character escape sequence (6:113) while parsing file: blueocean-plugin\blueocean-dashboard\target\jenkins-js-extension.jsx
[ERROR]
[ERROR] blueocean-plugin\blueocean-dashboard\node_modules\@jenkins-cd\js-builder\index.js:557
[ERROR] throw 'Browserify bundle processing error. See above for details.';
[ERROR] ^
[ERROR] Browserify bundle processing error. See above for details.

ググるとこれが出た。
[JENKINS-35180] transformToJSX handles Path string wrong on windows - Jenkins JIRA
[Blue Ocean] Build failure when compiling BlueOcean : Dashboard in a Windows 7 PC - Google グループ
[Blue Ocean] Build failure when compiling BlueOcean : Dashboard in a Windows 7 PC - Google グループ
まさにコレです。
ただ、コメントを見る限りではこれは既に修正済みのはず。
実際に、自分が clone してきたのにもちゃんと対策がされてました。

なんでだろう？とログとエラーが発生している jenkins-js-extension.jsx ファイルをよくよく見ていたら、これは "throw new Error" の行が問題で yaml ファイルのパスのパス区切りが "\" のままになってました。問題としては上記URLで言われているものと同じですね。

じゃあ、同じように replace すれば解決するはずだ。というわけで、jenkins-js-extension.jsx をファイルを生成している blueocean-plugin\js-extensions\@jenkins-cd\subs\extensions-bundle.js をチェック。
問題のパスは jsExtensionsYAMLFile に格納されていたので、以下の様に書き換えました。
//var jsExtensionsYAMLFile = findExtensionsYAMLFile();
var jsExtensionsYAMLFile = findExtensionsYAMLFile().replace(/\\/g, "/");

node_module(blueocean-plugin\blueocean-dashboard\node_modules\@jenkins-cd\js-extensions\@jenkins-cd\subs) の方が残っているかもしれないので、を削除しておいて再実行。

通った！


試しに使ってみる
blueocean のトップディレクトリで以下のコマンドを実行します。
mvn -f blueocean-plugin/pom.xml hpi:run

Jenkins が起動するので、 http://localhost:8080/jenkins/blue にアクセスします。
Jenkins 2.0 でおなじみのアンロック画面が出ます。


コンソール出力にパスワードが出ているのでコピペして進んでください。
次に、プラグインインストール画面が出るので、左のオススメインストールをします。
この辺は普通に Jenkins 2.0 をインストールするときと一緒なんで、説明は省きます。

Jenkins 2.0 の初期設定が終わるといつものページが開きます。


「Try Blue Ocean UI...」って出てますね！
ここをクリックすると…

ジョブがなんもないので Not Found です。
でも、これで Blue Ocean が使えるようになりました！

既存の Jenkins にインストールしてみる
上記方法で Blue Ocean が試せるようになりました。
でも、「自分は既にある Jenkins で Blue Ocean を使ってみたいんだ！」ということでやってみました。
といっても、他のプラグインと同様にパッケージをつくるだけです。

まず、以下のコマンドを実行します。
mvn package -DskipTests



成功すると blueocean-plugin や blueocean-web の target ディレクトリに .hpi が出来上がっています。
blueocean-plugin はそれぞれに依存しているので、以下のように .hpii を順次アップロードしていきます。
アップロードは、Jenkinsの管理＞プラグインの管理＞高度な設定タブのプラグインのアップロードからします。


  1. blueocean-web
  2. blueocean-common
  3. blueocean-rest
  4. blueocean-rest-impl
  5. blueocean-dashboard
  6. blueocean-plugin
（※ GitHub Branch Source Plugin と Favorite プラグインに依存しているので事前にインストールしておくこと）
（※ 他にも依存しているかもしれないのでインストールに失敗したらエラーログを確認しよう）

インストールが無事に終わるとこのようにマイ Jenkins にも Blue Ocean がやってきます。

Blue Ocean を開くと…






やっぱり Not Found
そうなんです。私の Jenkins ではまだ Pipeline を使ってないんです。。。

せっかくだし、始めてみようとしたのですが、なぜか上手くいかなかったので今回はナシとさせて頂きますm(__)m
もう色々面倒くさいし、コンソールログに警告がイッパイ出てるし、一から Jenkins 2.0 とパイプラインを構築しようと思います。

実際に使ってみたところは、それが出来たらで。
今回は以上。では～



投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)