5

統合テストを行うために jenkins-workflow をセットアップしようとしています。統合テストは次のように機能します。

LibraryA誰かがgit の機能ブランチに変更を加えました。jenkins に機能ブランチのコードに対して単体テストを実行させたいと考えています。次に、この機能ブランチのコードをclient1and client2(のユーザーであるLibraryA) にインストールしてテストを実行したいと考えています。

の機能ブランチへの適切なコミットを取得することを除いて、すべてを実行するワークフローをセットアップすることができましたLibraryA。代わりに、私のセットアップは、LibraryA.

多くのフィーチャー ブランチがあるため、ワークフロー セットアップで特定のブランチをハードコーディングすることは適切ではありません。ワークフロー ジョブをトリガーするコミットのハッシュを取得する方法が必要なようです (SCM ポーリングを使用している場合でも)。

私のセットアップは次のようになります。

currentBuild.setDisplayName("#" + env.BUILD_NUMBER)

node {
  git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: 'git@github.com:mycompany/myrepo.git'
  sh '''
echo `git rev-parse HEAD` > libraryA_version.txt
sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests
'''
  archive 'libraryA_version.txt'
}

def integration_jobs = [:]

integration_jobs[0]={
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt':'.']
      sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"'
    }
  }
}

integration_jobs[1] = {
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt' : '.']
      sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" '
    }
  }
}

parallel integration_jobs

したがって、私の現在の質問は、最初のテストで実行する適切なコミットを取得するために git リポジトリ/ポーリングをセットアップする方法です。これlibraryA_version.txtは後続のテストで使用されます。

または、このプロセスをまったく別の方法で行う必要がありますか?

4

2 に答える 2

4

@maybeg が示唆したように、探している可能性が最も高いのはマルチブランチ プロジェクトで、Pipeline: Multibranchをインストールすることで利用できます。これにより、ビルドで 1 回以上Jenkinsfile呼び出すだけでスクリプトを定義でき、 .checkout scmlibraryA_version.txt

それまでの間、私はあなたのプロジェクトの設定について疑問に思っています。あなたのgitステップはデフォルトの を使用していますbranch: 'master'。つまり、最初はブランチでのみポーリングし、masterこのブランチのみをチェックアウトする必要があります。Git プラグインはかなり複雑なので、これが壊れている可能性があります。適切なマルチブランチのサポートが保留されている間は、ワイルドカード ブランチ仕様を使用するように構成されたcheckoutステップをいつでも使用できGitSCMます。その場合、以前に構築されていない任意のブランチ ヘッドがチェックアウト用に選択され、トリック ( JENKINSgit-rev-parseの回避策を独自に再発見したと思います) -26100 ) はそのまま動作するはずです。

于 2015-07-21T14:48:31.113 に答える
0

The feature you are looking for is Build-Per-Branch and in my view it should be implemented accordingly through fit-for-purpose plugins.

  • Branching is done in git.

  • Jenkins must copy the build or build pipeline job to fit the branch and being able to build and test the branch.

  • After reintegration git must inform Jenkins and Jenkins must shut down the jobs.

I found this plugin:

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

And this plugin/tutorial:

http://entagen.github.io/jenkins-build-per-branch/

The implementation is strongly dependent on your scenario so i can't be more specific. I just say the challenges are:

  • Building Jenkins jobs that can run concurrently and independently.

  • Working with templates for Jenkins jobs.

  • Handling events between Jenkins and git.

In your case:

  • Build the whole process as a delivery pipeline from front to end.

  • If someone branches a step and implements a feature then copy the whole pipeline and run the whole pipeline.

  • Get this working then improve.

于 2015-07-11T11:48:37.790 に答える