jenkinsパイプラインを作成する場合、新しい変更をコミットして機能するかどうかを確認するのは非常に不便です。

コードをコミットせずにこれらをローカルで実行する方法はありますか？

パイプラインスクリプトは、その目的はすべてJenkinsをスクリプト化することなので、ローカルでは実行できません。（これは、Jenkinsfile短くして、実際にJenkinsの機能を処理するコードに限定するのが最善の理由の1つです。実際のビルドロジックは、1行shまたはbatステップで呼び出す外部プロセスまたはビルドツールで処理する必要があります。）

変更をJenkinsfileライブにテストしたいが、コミットせずに、1.14で追加されたリプレイ機能を使用する

JENKINS-33925は、自動テストフレームワークに必要なものを追跡します。

私にはうまくいく解決策があります。これは、Dockerで実行されているローカルジェンキンスと、コミットごとにローカルジェンキンスのパイプラインをトリガーするgit Webフックで構成されています。パイプラインをテストするためにgithubまたはbitbucketリポジトリにpushする必要がなくなりました。

これはLinux環境でのみテストされています。

この指示は少し長いですが、この作業を行うのはかなり簡単です。ほとんどのステップがあります。

これが必要です

• Dockerがインストールされ、動作しています。これはこの命令の一部ではありません。
• Dockerでローカルに実行されているJenkins。以下の方法を説明しました。
  • ローカルのJenkins Dockerユーザーがローカルのgitリポジトリからプルするための適切な権限（sshアクセスキー）。 以下の方法を説明しました。
  • ローカルのgitリポジトリから取得するJenkinsパイプラインプロジェクト。以下で説明します。
  • 最小限の権限を持つローカルJenkinsのgitユーザー。以下で説明します。
• パイプラインプロジェクトをトリガーするコミット後のWebフックを備えたgitプロジェクト。以下で説明します。

これがあなたのやり方です

ジェンキンス・ドッカー

選択した場所にDockerfileというファイルを作成します。私は/opt/docker/jenkins/Dockerfileそれをこれで埋めています：

FROM jenkins/jenkins:lts
USER root
RUN apt-get -y update && apt-get -y upgrade
# Your needed installations goes here
USER jenkins

local_jenkinsイメージをビルドする

これは、1回またはDockerfileに何かを追加した後に行う必要があります。

$ docker build -t local_jenkins /opt/docker/jenkins/

local_jenkinsを起動して再起動します

時々、jenkinsを簡単に起動および再起動する必要があります。たとえば、マシンの再起動後。このため.bash_aliases、ホームフォルダーに配置するエイリアスを作成しました。

$ echo "alias localjenkinsrestart='docker stop jenkins;docker rm jenkins;docker run --name jenkins -i -d -p 8787:8080 -p 50000:50000 -v /opt/docker/jenkins/jenkins_home:/var/jenkins_home:rw local_jenkins'" >> ~/.bash_aliases
$ source .bash_aliases  # To make it work

/opt/docker/jenkins/jenkins_homeフォルダーが存在し、ユーザーにそのフォルダーに対する読み取りおよび書き込み権限があることを確認してください。

jenkinsを起動または再起動するには、次のように入力します。

$ localjenkinsrestart

ローカルjenkinsで行うすべての作業は、/ opt / docker / jenkins / jenkins_homeフォルダーに保存され、再起動しても保持されます。

docker jenkinsにSSHアクセスキーを作成する

これは、これが機能するための非常に重要な部分です。まず、Dockerコンテナーを起動し、それにbashシェルを作成します。

$ localjenkinsrestart
$ docker exec -it jenkins /bin/bash

これで、Dockerコンテナーに入りました。これjenkins@e7b23bad10aa:/$は、ターミナルなどで確認できます。@の後のハッシュは確かに異なります。

キーを作成する

jenkins@e7b23bad10aa:/$ ssh-keygen

プロンプトが表示されるまで、すべての質問でEnterキーを押します

キーをコンピューターにコピーします。Dockerコンテナー内から、コンピューターは172.17.0.1になります。

jenkins@e7b23bad10aa:/$ ssh-copy-id user@172.17.0.1

user =ユーザー名、172.17.0.1は、Dockerコンテナー内からコンピューターへのIPアドレスです。

この時点でパスワードを入力する必要があります。

ここで、Dockerコンテナー内からコンピューターにssh-ingしてループを完了してみましょう。

jenkins@e7b23bad10aa:/$ ssh user@172.17.0.1

今回はパスワードを入力する必要はありません。そうした場合、何かがうまくいかず、もう一度やり直さなければなりません。

これで、コンピューターのホームフォルダーに移動します。ls見てみてください。

抜ける必要があるsshシェルのチェーンがあるので、ここで止めないでください。

$ exit
jenkins@e7b23bad10aa:/$ exit

正しい！これで戻ってきて、続行する準備ができました。

Jenkinsをインストールする

ローカルJenkinsは、ブラウザーのhttp：// localhost：8787にあります。

初めてブラウザでローカルのJenkinsを指定すると、インストールウィザードが表示されます。デフォルトで問題ありませんが、セットアップ中にパイプラインプラグインをインストールしてください。

ジェンキンスをセットアップする

http：// localhost：8787 / configureSecurityでマトリックスベースのセキュリティをアクティブにし、マトリックスに自分を追加してすべての権限を付与し、すべてのボックスにチェックマークを付けることが非常に重要です。（右端にチェックボックスのアイコンがあります）

• Jenkins’ own user databaseセキュリティレルムとして選択
• Matrix-based securityAuthorizationセクションで選択します
• フィールドにユーザー名を入力User/group to add:し、[ Add ]ボタンをクリックしてください
• 上の表で、ユーザー名の横に人のアイコンが表示されます。それが交差している場合は、ユーザー名を間違って入力しました。
• テーブルの右端に移動して[すべてチェック]ボタンをクリックするか、行のすべてのボックスに手動でチェックを入れます。
• チェックボックスPrevent Cross Site Request Forgery exploitsがオフになっていることを確認してください。（このJenkinsはコンピューターからしか到達できないため、これはそれほど大した問題ではありません）
• クリックして[ Save ]Jenkinsからログアウトし、再度ログインして、機能することを確認します。 そうでない場合は、最初からやり直して、/opt/docker/jenkins/jenkins_home再起動する前にフォルダを空にする必要があります

gitユーザーを追加する

最小限の権限でgitフックがローカルのJenkinsにログインできるようにする必要があります。ジョブを表示して構築するだけで十分です。したがってgit、passwordで呼び出されるユーザーを作成しますlogin。

ブラウザでhttp：// localhost：8787 / securityRealm / addUserにアクセスしgit、ユーザー名として追加し、loginパスワードとしてします。をクリックし[ Create User ]ます。

権限をgitユーザーに追加する

移動します。http：// localhostを：8787 / configureSecurityのページをブラウザで。gitユーザーをマトリックスに追加します。

• gitフィールドに書き込んでUser/group to add:クリック[ Add ]

次に、ボックスをチェックして、gitユーザーへの最小限の権限を確認します。これらだけが必要です：

• 全体：読み取り
• ジョブ：ビルド
• ジョブ：発見
• ジョブ：読み取り

確認してください Prevent Cross Site Request Forgery exploitsチェックボックスがオフになってクリックします[ Save ]

パイプラインプロジェクトを作成する

ユーザー名がuserあり、gitが有効になっているプロジェクトJenkinsfileが呼び出されproject、次の場所にあると想定します/home/user/projects/project

では、あなたのhttp：// localhostを：8787ジェンキンスは、新しいパイプラインプロジェクトを追加します。参照用に私はそれに名前を付けました。

• New ItemJenkinsメニューをクリックします
• プロジェクトに名前を付ける hookpipeline
• パイプラインをクリックします
• クリック [ OK ]
• Poll SCM[ビルドトリガー]セクションのチェックボックスをオンにします。スケジュールは空のままにします。
• パイプラインセクション：
  • 選択する Pipeline script from SCM
  • でRepository URLフィールド入力しますuser@172.17.0.1:projects/project/.git
  • でScript Pathフィールド入力しますJenkinsfile
• hookpipelineプロジェクトを保存する
• フックパイプラインを手動で1回ビルドします。これは、ポーリングSCMが機能するために必要です。

gitフックを作成する

/home/user/projects/project/.git/hooksフォルダーに移動し、次の内容post-commitを含むというファイルを作成します。

#!/bin/sh
BRANCHNAME=$(git rev-parse --abbrev-ref HEAD)
MASTERBRANCH='master'

curl -XPOST -u git:login http://localhost:8787/job/hookpipeline/build
echo "Build triggered successfully on branch: $BRANCHNAME"

このファイルを実行可能にします。

$ chmod +x /home/user/projects/project/.git/hooks/post-commit

コミット後のフックをテストします。

$ /home/user/projects/project/.git/hooks/post-commit

フックパイプラインプロジェクトがトリガーされたかどうかをJenkinsで確認します。

最後に、プロジェクトに任意の変更を加え、変更を追加してコミットします。これにより、ローカルのJenkinsでパイプラインがトリガーされます。

幸せな日々！

TL; DR

• Jenkins Pipelineユニットテストフレームワーク
• Jenkinsfileランナー

ロングバージョンの
Jenkins Pipelineテストはますます面倒になります。ユーザーがUIが公開したものに制限されていた従来の宣言型ジョブ構成アプローチとは異なり、新しいJenkins Pipelineは、宣言部分と独自のコードを組み合わせるビルドプロセス用の本格的なプログラミング言語です。優れた開発者として、この種のコードについてもいくつかの単体テストが必要です。

Jenkins Pipelinesを開発する際に従うべき3つのステップがあります。ステップ1.使用症例の80％をカバーしなければなりません。

1. ビルドスクリプト（Maven、Gradle、Gulpなど）でできる限り実行します。次に、パイプラインスクリプトで、正しい順序でビルドタスクを呼び出します。ビルドパイプラインは、ビルドタスクを調整および実行するだけですが、特別なテストを必要とする主要なロジックはありません。
2. 前のルールを完全に適用できない場合は、独自のカスタムロジックを開発してテストし、それらをパイプラインに統合できるパイプライン共有ライブラリに移動します。
3. 上記のすべてが失敗した場合は、最近登場したライブラリ（2017年3月）のいずれかを試すことができます。JenkinsパイプラインユニットテストフレームワークまたはpipelineUnit（例）。2018年以降、コマンドラインツールからJenkinsパイプラインを実行するためのパッケージであるJenkinsfile Runnerもあります。

例

pipelineUnit GitHubのレポを使用する方法についていくつかのスポックの例が含まれジェンキンスパイプラインユニットテストフレームワークを

Jenkinsには「リプレイ」機能があり、ソースを更新せずにジョブをすばやくリプレイできます。

執筆の時点（2017年7月末）でBlue Oceanプラグインを使用すると、ビジュアルパイプラインエディターで宣言的パイプラインの構文を直接確認できます。エディターは、githubプロジェクトに対してのみ「構成」をクリックすると、Blue Ocean UIから機能します（これは既知の問題であり、gitなどでも機能するように機能しています）。

ただし、この質問で説明されているように、エディターを開いて以下を参照できます。

[Jenkins URL]/blue/organizations/jenkins/pipeline-editor/

次に、ページの中央をクリックしてを押すCtrl+Sと、テキストエリアが開き、パイプライン宣言スクリプトを貼り付けることができます。[ 更新 ]をクリックすると、構文エラーがある場合、エディターは構文エラーの場所を通知します。このスクリーンショットのように：

構文エラーがない場合、textareaが閉じ、ページにパイプラインが表示されます。何も保存されないことを心配しないでください（githubプロジェクトの場合は、Jenkinsfileの変更をコミットします）。

私はJenkinsを初めて使用しましたが、これは非常に役立ちます。これがないと、Jenkinsfileが機能するまで何度もコミットする必要がありました（非常に迷惑です！）。お役に立てれば。乾杯。

パーティーには少し遅れましたが、それが私がjennyJenkinsfileのコアステップの小さな再実装を書いた理由です。（https://github.com/bmustiata/jenny）

私の知る限り、このパイプラインプラグインは新しいJenkinsfileメカニズムの「エンジン」であるため、これを使用してスクリプトをローカルでテストすることができます。

Jenkinsfileにコピーするときに追加の手順が必要かどうかはわかりませんが、構文などはまったく同じです。

編集：「エンジン」のリファレンスを見つけました。この機能の説明、最後の段落、最初のエントリを確認してください。

私の開発セットアップでは、適切なGroovyエディターが欠落しています。Jenkinsfileの問題の多くは、単純な構文エラーが原因です。この問題に取り組むには、Jenkinsインスタンス（で実行中$JENKINS_HTTP_URL）に対してJenkinsfileを検証できます。

curl -X POST -H $(curl '$JENKINS_HTTP_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)') -F "jenkinsfile=<Jenkinsfile" $JENKINS_HTTP_URL/pipeline-model-converter/validate

上記のコマンドは、https：//github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Validating-（or-linting）-a-Declarative-Jenkinsfile- from - the-command- lineからわずかに変更されたバージョンです 。

他の人がすでに述べたリプレイ機能（その有用性については同じです！）を除いて、私は次のことも役立つことがわかりました。

1. パイプラインコードを入力するか、Jenkinsfileのリポジトリ/ブランチをポイントして、何かをすばやくテストできるテストパイプラインジョブを作成します。より正確なテストを行うには、独自のフォークを指すマルチブランチパイプラインを使用します。ここで、prodに影響を与えることなく、すばやく変更を加えてコミットできます。BRANCH_NAME envのようなものは、Multibranchでのみ使用できます。
2. JenkinsfileはGroovyコードなので、「groovy Jenkinsfile」を指定して呼び出すだけで、基本的な構文を検証できます。

SSH鍵をJenkinsプロファイルに入れ、次のように宣言型リンターを使用します。

ssh jenkins.hostname.here declarative-linter < Jenkinsfile

これにより、Jenkinsfileの静的分析が行われます。任意のエディターで、そのコマンドを自動的に実行するキーボードショートカットを定義します。私が使用しているVisual Studio Codeで、[タスク]> [タスクの構成]に移動し、次のJSONを使用してJenkinsfile検証コマンドを作成します。

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Validate Jenkinsfile",
      "type": "shell",
      "command": "ssh jenkins.hostname declarative-linter < ${file}"
    }
  ]
}

私はいくつかの更新を行い、迅速に実行するために、replay futureを使用しています。

いくつかの制限があり、スクリプトパイプラインでは、このソリューションを使用します。

1. インラインのgroovyスクリプトを使用したパイプラインジョブ：

node('master') {
    stage('Run!') {
                def script = load('...you job file...')
    }
}

2. テスト用のJenkinsfileは、レスフレと同じ構造です。

def execute() {
 ... main job code here ...
}
execute()