web-dev-qa-db-ja.com

Gitlab Webhookがjenkinsでビルドをトリガーしない

次のグルーヴィーなスクリプトで生成されたマルチブランチパイプラインジョブのグループがあります。

[
      'repo1',
      'repo2',
].each { service ->

  multibranchPipelineJob(service) {

    displayName(service)

    branchSources {
      git {
        remote("[email protected]:whatever/${service}.git")
        credentialsId('gitlab-ssh-key')
      }
    }

    orphanedItemStrategy {
      discardOldItems {
        daysToKeep(0)
        numToKeep(30)
      }
    }

    triggers {
      periodic(5)
    }

  }
}

そして各レポでJenkinsfileは次のようになります：

#!/usr/bin/env groovy

properties([
      gitLabConnection('[email protected]'),
      pipelineTriggers([
            [
                  $class               : 'GitLabPushTrigger',
                  triggerOnPush        : true,
                  triggerOnMergeRequest: true,
            ]
      ]),
      disableConcurrentBuilds(),
      overrideIndexTriggers(false)
])

node {

  def sbtHome = tool name: 'sbt-0.13.15', type: 'org.jvnet.hudson.plugins.SbtPluginBuilder\$SbtInstallation'

  stage('Checkout') {
    checkout scm
  }

  stage('Build') {
    sh "'${sbtHome}/bin/sbt' clean compile"
  }

  stage('Test') {
    sh "'${sbtHome}/bin/sbt' test"
  }

  if (env.BRANCH_NAME == 'develop' || env.BRANCH_NAME == 'master') {
    stage('Publish') {
      sh "'${sbtHome}/bin/sbt' publish"
    }
  }
}

すべて正しく動作します。 seederプロジェクトは最初のスクリプトからすべてのフォルダーを生成し、指定されたリポジトリーのすべてのブランチが正しく構築されます。

残念ながら、gitlabにコミット+プッシュが行われた後、ブランチのビルドをトリガーする際に問題があります。

私はjenkinsを正しく構成しました-gitlabプラグインを意味します、接続があり、すべてうまくいきます。

Gitlab側にもwebhookを追加しましたが、正しく動作します。テストプッシュが送信された後、200 OK jenkinsから、ブランチのスキャンが開始され、変更が正しく検出されたことをログで確認しています。残念ながら、変更されたブランチのビルドは開始されません。次に、ブランチスキャンログからの抜粋を示します。

  Checking branch ci
      ‘Jenkinsfile’ found
    Met criteria
Changes detected: ci (a7b9ae2f930b0b10d52bb42f1ecf96a68bba4a30 → 39a4c1a65051d5e90079feec14ad22455a77c58e)
Did not schedule build for branch: ci

これは私のjenkinsインスタンスとgitlabアカウント間の通信に問題がないことを100％確信しています。 gitlabへのプッシュ後にWebhookがトリガーされ、リクエストが送信され、ブランチスキャンが実行されているのがわかります。変更も検出されますが、なぜジョブが開始されないのですか？docs も完全に読んで、すべて正しく構成されています。

Jenkins version: 2.150.3
Gitlab version: 11.8.1-ee

[〜＃〜]編集[〜＃〜]

Jenkinsをv.2.164.1にアップグレードした後、すべて正常に動作し始めたようです。

gitjenkinsgroovygitlabjenkins-pipeline
17
Opal

私はこれが非常に便利であることを発見しました 設定例 （ JenkinsおよびGitLabとの継続的な統合 ）。特に部分ソースコード管理：

他のセクションで使用される「Origin」として名前を指定する必要があります。 Refspecの場合、次のように入力する必要があります：+refs/heads/*:refs/remotes/Origin/* +refs/merge-requests/*/head:refs/remotes/Origin/merge-requests/*

そしてまた：

必要なブランチ指定子Origin/${gitlabSourceBranch}は、次に設定するWebフックに基づいて入力されます。

Edit1

1つのマルチブランチパイプラインに対して次のことを試すことができます。

  1. ブランチを選択します（例：ci）
  2. 「構成の表示」を選択します
  3. [ビルドトリガー]の下の[変更がGitLabにプッシュされたときにビルドする]チェックボックスを選択します
  4. コードに変更を加えて、ciにプッシュします。

Edit2

実行に適したgitプロジェクトが見つからず、この動作を再現することができませんでした。したがって、誰かが同様のプロジェクトを知っていて共有できる場合は、コメントしてください。さらにテストを行うことができます。

Gitlabの場合（試用キーを要求した場合 それ以外の場合はGitLab Community Editionになります ）：

Sudo docker run --detach --hostname gitlab.example.com --publish 443:443 --publish 80:80 --publish 22:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ee:11.8.1-ee.0

Jenkinsの場合：

Sudo docker run  -u root  --rm  -d  -p 8080:8080  -p 50000:50000  -v jenkins-data:/var/jenkins_home  -v /var/run/docker.sock:/var/run/docker.sock  jenkins/jenkins:2.150.3

次に、「Integration」—>「Jenkins CI」のようにGitlabでこの画像： - enter image description here

これがあなたに役立つことを願っています！

4
Anton Bärwald

includes() を使用して、どのブランチが含まれるかを識別するパターンを指定する必要があると思います。

_branchSources {
  git {
    remote("[email protected]:whatever/${service}.git")
    credentialsId('gitlab-ssh-key')
    includes('ci')
  }
}
_

ワイルドカードを含むことができるいくつかのパターンを指定できます。例えば：

_includes("master release/* feature/* bugfix/*")
_

さらに細かい制御のために対応するexcludes()もあります。

3
cody

おそらく、特定のブランチのみを含めるように Basic Branch Build Strategies を設定しました。正確な名前：masterを使用すると、例からブランチciをスキップします。

Jenkinsブランチのビルド構成がテスト対象のブランチをカバーしていることを確認してください。 SCMの自動トリガーを抑制する オプションが設定されていないことも確認してください。

組織またはフォルダレベルの設定は、下位レベルで特に上書きされない限り、特定のプロジェクトおよびジョブの設定に影響することに注意してください。

3
Karol Dowbecki

私たちはgitlabとJenkinsで同様の（同じではない）問題に直面しており、問題は資格情報に関連していました。

Jenkinsでは、GitLabの新しいグローバルアクセストークンを作成しました（Jenkins構成->認証情報->システム->新しいグローバルアクセス-> gitlabトークンの定義）。これにより、Webhookに追加したトークンが生成され、フックは次のようになります。

http://[Gitlab User]:[token ID]@Jenkins Address

それが役に立てば幸い

1
Jose Camacho