Веб-перехватчик Bitbucket создает сборку в неправильном репозитории GIT

Я хочу запустить конвейер на моем 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"

Итак, в компоненте «источник» я ссылаюсь на репозиторий git, в котором находится мой Jenkinsfile. Таким образом, у меня может быть много конвейеров с одним централизованным файлом Jenkins. Обратите внимание, что это репо полностью отличается от местоположения 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.

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

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


jenkins openshift webhooks jenkins-pipeline pipeline
person César Pereira    schedule 05.02.2019    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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 ?
person Guru    schedule 05.02.2019
comment
Пробовал, такая же проблема. Хотя спасибо за ответ - person César Pereira; 05.02.2019
comment
Ошибка выглядит так, будто вы используете несуществующую ссылку (ветку / тег). Попробуйте указать правильную ветку и тег, используя параметры ветки / тега. Вы также можете использовать хеш фиксации напрямую, используя опцию ref. Также убедитесь, что ваш URL-адрес git правильный (ваш код не содержит части xxx.git). - person Guru; 05.02.2019
comment
Ветвь указана в моем текущем шаблоне. uri - это URL-адрес git, считываемый из переменной среды APPLICATION_GIT_JENKINSFILE_REPO. ref - это ветка - person César Pereira; 05.02.2019
comment
после git fetch он должен сделать git rev-parse origin/master, в вашем случае он пытается получить хэш, единственное изменение, которое я могу рекомендовать, изменить приоритет использования ref после URI и повторить попытку. - person Guru; 05.02.2019

arrow_upward
0
arrow_downward

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

В основном текущее решение выглядит так:

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

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

person César Pereira    schedule 12.02.2019