Jenkins запускает задания при изменении мастера, хотя настроен иначе - PullRequest
Новая
       121

Jenkins запускает задания при изменении мастера, хотя настроен иначе

0 голосов
/ 13 июля 2020

У нас есть экземпляр Jenkins, полностью настроенный через Cas C. Как только мы выпустили эту версию, мы заметили некоторые проблемы с поведением github-branch-source и workflow-multibranch.

Мы пытаемся сканировать организацию, идентифицируя все репозитории с помощью Jenkinsfile, но не запуская задания сборки, особенно для веток, где изменилась только цель (мастер). Мы достигли определенного уровня успеха со следующей конфигурацией:

  1. Отключены «Триггеры дочернего сканирования»
  2. Параметр «Игнорировать перестроение ветвей слияния, когда изменилась только целевая ветвь» с basic-branch-build-strategies
  3. Настройка «Пропустить начальную сборку при индексировании первой ветки»

С их помощью мы можем идентифицировать новые репозитории с помощью Jenkinsfile во время OrgScan, но не запускать какую-либо сборку PR без необходимости.

Приведенные выше конфигурации работают нормально, если Jenkins не перезапустится. В случае любого перезапуска триггеры сканирования репозитория, и хотя у нас есть «Игнорировать перестроение ветвей слияния, когда изменилась только целевая ветвь», планируется построить PR, в которых изменился только мастер, как показано ниже, 

    Checking pull request #5417
      ‘Jenkinsfile’ found
    Met criteria
Changes detected: PR-5417 (7202a80c95188db87f98ccf62157fdd76d41a206+81e38fbefa404bcbad7968ad07cd522acf68be8b (3017360542722f016bb24c584bf55b3fa88f4921) → 7202a80c95188db87f98ccf62157fdd76d41a206+65343d82d5966e02b2889a4b2c9582e8d3e46362 (02e307214a15d7f192236994695578d6b8dacb08))
Scheduled build for branch: PR-5417

Это огромная проблема, особенно с учетом того, что в какой-то момент у нас может быть одновременно открыто более 50 PR для одного репозитория в этой организации, не говоря уже о других репозиториях. Это не только потребляет много ресурсов, но и делает наш Jenkins бесполезным до тех пор, пока этот большой объем не будет обработан.

Есть ли способ гарантировать, что сканирование новых репозиториев не будет запущено перезапуском Jenkins? Или, что еще лучше, есть ли способ принудительно игнорировать перестроение ветвей слияния, когда только целевая ветка изменилась на уровне репозитория?

Ответы [ 2 ]

0 голосов
/ 15 июля 2020

В настоящее время нет способа обойти это, пока вы не построите его хотя бы один раз. сохранить информацию о запросе на изменение. В отсутствие этой информации, когда Дженкинс получает последующий хук, он не может выполнить сравнение, чтобы решить, должна ли запускаться сборка или нет. Поэтому он просматривает конфигурацию и обнаруживает, что для этого уже существует задание (т. Е. Оно не квалифицируется как начальная сборка) и что запросы на изменение включены. Итак, он запускает сборку.

После первой сборки файл становится доступным по адресу $JENKINS_HOME/jobs/<my-repo>/branches/PR-1/builds/1/build.xml. Помимо прочего, он содержит следующую информацию, относящуюся к запросам на изменение (обратите внимание на хеши): 

<revision class="org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision" plugin="github-branch-source@2.5.8">
    <head class="org.jenkinsci.plugins.github_branch_source.PullRequestSCMHead">
        <name>PR-1</name>
        <merge>true</merge>
        <number>1</number>
        <target>
            <name>master</name>
        </target>
        <sourceOwner>ORG</sourceOwner>
        <sourceRepo>my-repo</sourceRepo>
        <sourceBranch>my/feature-branch</sourceBranch>
        <origin class="jenkins.scm.api.SCMHeadOrigin$Default" plugin="scm-api@2.6.3"/>
    </head>
    <target class="jenkins.plugins.git.AbstractGitSCMSource$SCMRevisionImpl" plugin="git@4.0.0">
        <head class="org.jenkinsci.plugins.github_branch_source.BranchSCMHead" reference="../../head/target"/>
        <hash>9501c1d2dd5b29nso488909ec2b0aac14208b28</hash>
    </target>
    <baseHash>9501c1d2dd5b29nso488909ec2b0aac14208b28</baseHash>
    <pullHash>du65a39j39j24368ab6561d260093e78d69b20549</pullHash>
    <mergeHash>9d62w889092ef74c6a7a2d67897e91d70wb73hs8</mergeHash>
</revision>
0 голосов
/ 15 июля 2020

Хорошо, ребята, я думаю, что нашел ответ в исходном коде плагина branch-api.

Похоже, проблема здесь, https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/MultiBranchProject.java#L2246 -L2257 (по состоянию на 07 / 15/2020, v2.5.6). Он всегда будет возвращать истину для любой ветви / PR, если какая-либо из стратегий сборки вернет true.

У меня были следующие три стратегии вместе:

  1. jenkins.branch.buildstrategies.basic.ChangeRequestBuildStrategyImpl
  2. jenkins.branch.buildstrategies.basic.NamedBranchBuildStrategyImpl
  3. jenkins.branch.buildstrategies.basic.SkipInitialBuildOnFirstBranchIndexing

Оказывается, SkipInitialBuildOnFirstBranchIndexing всегда будет возвращать true, если это не первая индексация ветки этого репозитория, отображая конфигурации на ChangeRequestBuildStrategyImpl бесполезны.

Я не уверен, является ли это ожидаемым поведением плагина branch-api и создал ошибку в их Jira, https://issues.jenkins-ci.org/browse/JENKINS-63088. Хотя проблема не устранена, я удалил SkipInitialBuildOnFirstBranchIndexing и укусил пулю, предполагая, что fre sh экземпляр Jenkins будет иметь огромные накладные расходы на создание всех PR и ветвей при первом сканировании.

Надеюсь, это объяснение поможет кому-нибудь с той же проблемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...