Миграция многоотраслевого конвейера без восстановления всех веток

Question

Я унаследовал по-настоящему древний сервер Jenkins, который нуждался в перестройке с операционной системы, и я собираюсь перенести наши сборки. Однако, в частности, существует один многоотраслевой конвейер с десятками ветвей и сборок feature / bugfix / et c, которые занимают значительное количество времени и ресурсов. Когда я изначально настроил его многоотраслевой конвейер на тестовом кластере, начальные сборки всех веток монополизировали все ресурсы в течение нескольких часов, пока я их не уничтожил.

Я хотел бы, чтобы все ветки были изначально импортированы, но не строится, пока не появится еще один пу sh или пиар для ветки. В настоящее время я применил определенную стратегию «Подавить автоматизацию c SCM», но как только я уберу ее, Дженкинс попытается построить все ветви. состояние каждой ветви отличается от «Not Built», а затем удалите стратегию подавления.

Я запустил скрипт ниже Groovy, который изменит результат конкретной сборки, но это Кажется, требуется, чтобы на самом деле была предыдущая сборка для изменения статуса.

import com.cloudbees.groovy.cps.NonCPS
import jenkins.model.*
import hudson.model.Result

@NonCPS
def getProject(projectName) {
    // CloudBees folder plugin is supported, you can use natural paths:
    // in a postbuild action use `manager.hudson`
    // in the script web console use `Jenkins.instance`
    def project = jenkins.model.Jenkins.instance.getItemByFullName(projectName)
    if (!project) {error("Project not found: $projectName")}
    return project
}

project = getProject('foo/bar')
build = project.getBuildByNumber(2443)
// build = project.getBuild(project, '2443')

build.@result = hudson.model.Result.SUCCESS
// build.@result = hudson.model.Result.NOT_BUILT
// build.@result = hudson.model.Result.UNSTABLE
// build.@result = hudson.model.Result.FAILURE
// build.@result = hudson.model.Result.ABORTED

Источник: { ссылка }

Есть ли способ изменить статус самого проекта или способ создания "фиктивной" сборки с определенным статусом?

Answer 1

Примечание: Если вы просто хотите заданий и не заботитесь об истории сборки, плагин Job Import , вероятно, подойдет для вашего случая использования. гораздо аккуратнее.

Большую часть последнего дня я потратил на то, чтобы копаться в источнике Дженкинса и беспокоить сообщество, но, похоже, нет хорошего способа подделать результаты сборки, такие как это. Однако технически возможно просто клонировать над всеми или частями /var/jenkins_home/jobs, которые полностью сохранят конфигурацию задания и историю. После этого вам просто нужно перезапустить Jenkins, чтобы он распознал новую конфигурацию.

В то время как некоторые из сообщества Jenkins правильно попытаются предупредить вас о клонировании таких данных, если вы ' он застрял без других опций, он может работать по-разному со следующими предостережениями:

1. Сначала выполните это на тестовом сервере. Я не могу гарантировать, что мой опыт универсален, и результаты могут отличаться дико в зависимости от ваших конкретных сборок и плагинов.
2. Ваши старые сборки, скорее всего, будут ссылаться на плагины, которые вы, возможно, не установили на новом сервере, или плагины разные версии. По моему опыту Дженкинс поднял «Старые данные» уведомления об этом, а также установил недостающие плагины и перезапустил исправил их. Также есть возможность просто отбросить данные.