Jenkins GitLab Plugin группировка коммитов

#1

Добрый день.

Проблема:
Имеем Jenkins и GitLab и настройку их взаимодействия, которую не сложно найти в интернете.
При этом, если в процессе сборки в GitLab помещаются новые коммиты, то в Jenkins они группируются. В нашем случае это выглядит некрасиво, т.е.:

  • выполняется сборка 1 по коммиту 1
  • в плане сборка 2 по коммиту 2, 3
  • в плане сборка 3 без изменений (т.е. без изменений относительно сборки 2, т.е. по коммиту 3).

Хотелось бы иметь возможность выполнять сборку (в т.ч. и тесты) по каждому коммиту отдельно.

В интернете нашел описание этой проблемы и решение такое: в настройке проекта (сборочной линии/pipeline) в разделе настройки git добавить подраздел “Branches to build” и в поле “Branch Specifier (blank for ‘any’)” ввести значение “${GIT_COMMIT}” (текущее у нас “*/master”).
Но это решение не подходит.
Также нашел в интернете описание переменных, которые создает GitLab Plugin - там вообще про коммит не нашел, но даже “${gitlabBranch}” не дает результата - т.е. в выводе консоли Jenkins вижу ошибку при выполнении этой команды (как и в случае использования GIT_COMMIT).

Подскажите, как вы решаете эту проблему?

#2

Не совсем понятна “некрасивость”: у вас запускается одновременно несколько задач на одну ветку и иодни и те же коммиты попадаюют в разные сборки?
Если так, то используйте блокировку конкурирующих сборок.

В скриптовом пайплайне это properties([disableConcurrentBuilds()])

#3

Нет.
Настройка декларативная, т.е. при настройке проекта в Jenkins указываем настройки подключения к GitLab. Если бы я понимал как описать pipeline в виде скрипта - вопроса бы не возникло.

Получается следующая ситуация:

  1. GitLab сервер почувствовал новый commit и сообщил об этом в Jenkins (триггером)
  2. Jenkins создал новый build (поставил его в план, т.к. свободных slave’ов нет)
  3. Пока slave Jenkins не освободится GitLab уже накидал несколько build’ов в план Jenkins’a (допустим было 3 commit’a и в плане появилось 3 build’a)
  4. Jenkins нашел свободный slave и поручил ему выполнить очередной build согласно очереди
  5. Первым этапом происходит “Declarative checkout SCM” - вот это не отображается в jenkins файле, по сути наоборот он этим этапом обновляет jenkins-файл, чтобы использовать его как настройку остальных этапов.
  6. Первый этап получает все изменения git на текущий момент (т.е. все 3 commit’a он получит и сделает build)
  7. Далее Jenkins запустим согласно очереди еще 2 build’a, которые уже не получат изменений и выполнятся “вхолостую”

Ранее я написал, что хотелось бы изменить такое поведение, чтобы 1 commit - 1 build.

Соответственно вопросы:

  1. Возможно ли это сделать при декларативном описании pipeline?
  2. Возможно данный подход (1commit - 1 build) не правильный технологически/методологически?
  3. Нормально ли для Jenkins, что build’ы выполняются “вхолостую”, либо нужно правильно настроить?
#4

про декларативный не скажу, но примерно также должно быть.

при создании job я делаю так (кусок кода)

pipelineJob(jobName) {
	definition {
		cps {
			script(readFileFromWorkspace("Jenkinsfile${branchName}"))
		}
	}
	properties {
		disableConcurrentBuilds()  
	}
}
#5

Для декларативного здесь

disableConcurrentBuilds

Disallow concurrent executions of the Pipeline. Can be useful for preventing simultaneous accesses to shared resources, etc. For example:  `options { disableConcurrentBuilds() }`
#6

а вот это не знаю как сделать, да не понятно - зачем

#7

В интернете нашел описание этой проблемы и решение такое: в настройке проекта (сборочной линии/pipeline) в разделе настройки git добавить подраздел “Branches to build” и в поле “Branch Specifier (blank for ‘any’)” ввести значение “${GIT_COMMIT}” (текущее у нас “*/master”).
Но это решение не подходит.

Какой результат дает это решение?

#8

Эта настройка указывает ветки, на которые будет реагировать jenkins при дергании хука. Остальные будет игнорировать.