Bitbucket webhook, генерирующий сборку в неправильном GIT-хранилище - PullRequest
Новая
       89

Bitbucket webhook, генерирующий сборку в неправильном GIT-хранилище

0 голосов
/ 05 февраля 2019

Я хочу запустить конвейер на моем OpenShift, когда событие происходит в битовой корзине (например, push).Я правильно настроил веб-крючок, следуя инструкциям на страницах документации Openshift.Хотя мне пришлось изменить шаблон Openshift моего конвейера, что вызвало некоторые конфликты.

BuildConfig выглядит следующим образом: 

- apiVersion: "v1"
  kind: "BuildConfig"
  metadata:
    name: "${SERVICE_NAME}-pipeline"
  spec:
    source:
      contextDir: '${APPLICATION_GIT_JENKINSFILE_REPO_CONTEXT_DIR}'
      git:
        ref: master
        uri: '${APPLICATION_GIT_JENKINSFILE_REPO}'
      sourceSecret:
        name: git-secret
      type: Git
    strategy:
      jenkinsPipelineStrategy:
        jenkinsfilePath: Jenkinsfile
    triggers:
    type: "Bitbucket"
    bitbucket:
        secretReference:
            name: "mysecret"

Итак, в компоненте 'source' я ссылаюсь на репозиторий git, где находится мой Jenkinsfile.Таким образом, у меня может быть много конвейеров с одним централизованным Jenkinsfile.Обратите внимание, что это хранилище полностью отличается от местоположения API-интерфейса, в котором я настраиваю веб-крючок.

Этот подход не работает при автоматическом запуске из-за того, что полезная нагрузка, отправляемая в Openshift, имеет идентификатор фиксации.изменений соответствующего хранилища API.Openshift (я не знаю почему) пытается связать этот коммит с репо, присутствующим в этом шаблоне (репозиторий Jenkinsfile).

Журналы следующие: 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url http://jenkinsfile-repo.git # timeout=10
Fetching upstream changes from http://jenkinsfile-repo.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials git-secret
 > git fetch --tags --progress http://jenkinsfile-repo.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit} # timeout=10
hudson.plugins.git.GitException: Command "git rev-parse 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}" returned status code 128:
stdout: 79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}

stderr: fatal: ambiguous argument '79370e4fa88f19c693d85d82fbdbed77620d048b^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2016)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1984)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1980)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1612)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1624)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:809)
    at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
    at hudson.plugins.git.RevisionParameterAction.toRevision(RevisionParameterAction.java:98)
    at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1070)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1187)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:144)
    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

Здесь мы можем увидеть поведение, которое я пытался объяснить, '79370e4fa88f19c693d85d82fbdbed77620d048b' был идентификатором коммита на репозитории api, к которому OpenShift пытаетсяассоциировать с репозиторием Jenkinsfile.

Если бы я мог, например, игнорировать полезную нагрузку, проблема бы не существовала.

Спасибо за помощь.

Ответы [ 2 ]

0 голосов
/ 12 февраля 2019

Мне удалось реализовать обходной путь, хотя я до сих пор не понимаю, почему происходит указанное мной ранее поведение.

По существу, текущее решение выглядит следующим образом:

Шаблон openshift ссылается на GIT-репозиторий соответствующего API, и этот репозиторий имеет свой собственный Jenkinsfile, который одинаков для каждого API.Хотя единственное, что делает этот Jenkinsfile, - это вызывает отличный сценарий, который централизован в отдельном репозитории GIT и объявлен как общая библиотека в Jenkins.

Таким образом, если мы должны что-то изменить, например, стадию конвейера, нам нужно изменить только в одном месте, что было целью с самого начала.

0 голосов
/ 05 февраля 2019

Не думаю, что вам требуется тип put: git (duplicate), а также попробуйте использовать https: // URL-адрес bitbucket, 

source:
  contextDir: '${APPLICATION_GIT_JENKINSFILE_REPO_CONTEXT_DIR}'
  git:
    ref: master
    uri: '${APPLICATION_GIT_JENKINSFILE_REPO}'
  sourceSecret:
    name: git-secret
  type: Git *****remove and try ?
...