У меня Дженкинс работает в док-контейнере. Теперь я хочу начать свои сборки на докере. Но то, что я вижу в журнале, это то, что объем рабочей области монтируется в контейнер докера для сборки.
Означает ли это, что все мои сборки выполняются в одной папке рабочей области? Это именно то, что я хотел предотвратить.
Как я могу гарантировать, что проверка git выполняется в контейнере докеров и удаляется после запуска этой сборки?
+docker build -t c477d0c74731a417e6e0ba1563a397aad8ab76ee --target builder -f cpp/Dockerfile cpp
Sending build context to Docker daemon 1.307MB
...
Successfully built 4bc8ce7a4ad3
Jenkins seems to be running inside container 11e315121188683c9e1c7e02d5924a7a550324b8f9957f6cae580f80d04359db
$ docker run -t -d -u 1000:1000 -w /var/jenkins_home/jobs/Docker-Cpp-Demo/branches/master/workspace --volumes-from 11e315121188683c9e1c7e02d5924a7a550324b8f9957f6cae580f80d04359db
Из этого журнала я вижу, что --volumes-from
монтирует тома из экземпляра Jenkins. И что рабочее пространство находится в /var/...
. Означает ли это, что это общий том и, следовательно, он не очищается после сборки?
Дженкинсфайл:
pipeline {
agent {
dockerfile {
dir 'cpp'
additionalBuildArgs '--target builder'
}
}
stages {
stage('Build') {
steps {
dir('cpp') {
sh 'cmake -S . -B build -DCMAKE_INSTALL_PREFIX=install'
sh 'cmake --build build --target install'
}
}
post {
success {
archiveArtifacts artifacts: 'cpp/install/**'
}
}
}
}
}
Докерфайл:
FROM gcc:10.2.0 AS builder
# Install cmake
RUN apt-get update && apt-get -y install cmake
Но это по-прежнему будет означать, что две сборки одной и той же ветки не могут выполняться одновременно, поскольку она использует совместное рабочее пространство. Я надеялся, что докер решит эту проблему для меня.
Не могли бы вы объяснить свой сценарий, я имею в виду ваши шаги сборки? так что я попытаюсь сделать пример. Если я правильно понимаю, вы хотите запустить одну и ту же сборку ветки в 2 разных сценариях, но не хотите, чтобы Дженкинс делил рабочее пространство? Ваш сценарий кажется мне интересным, и я люблю попробовать его для демонстрации.
@SamitKumarPatel Предположим, кто-то делает две фиксации довольно близко друг к другу. Мой экземпляр Jenkins может запускать 8 сборок параллельно. Поэтому вполне вероятно, что две сборки в одной и той же ветке запускаются одновременно. И они будут работать в одном рабочем пространстве. Это то, чего я хочу избежать. Сами шаги сборки не имеют значения в этом случае.
Я не думаю, что Дженкинс когда-либо использует одно и то же рабочее пространство, если для работы выполняется параллельная сборка. Если нет одновременного, он использует одно и то же рабочее пространство. Проверьте мой пример ниже и наблюдение
Дженкинсфайл
node("master") {
stage('one') {
sh """
echo "Hello World - $BUILD_ID" >> file.txt
sleep 5
ls -al
cat file.txt
"""
}
}
Рабочее пространство в jenkins_home будет выглядеть так
На снимке экрана видно, что для одного и того же одновременного задания Дженкинс использует другую папку рабочей области, а соглашение об именах, которому следовал Дженкинс, было <JOB_NAME>@<CONCURENT_NUMBER>.
С агентом сборки Docker сценарий тот же.
Дженкинсфайл
pipeline {
agent {
docker {
image 'alpine:latest'
label 'master'
}
}
stages {
stage('one'){
steps {
sh """
echo "Hello World - $BUILD_ID" >> file.txt
sleep 5
ls -al
cat file.txt
"""
}
}
}
}
Журнал сборки
docker run -t -d -u 1000:1000 -w /var/jenkins_home/workspace/declarative-pipeline -v /var/jenkins_home/workspace/declarative-pipeline:/var/jenkins_home/workspace/declarative-pipeline:rw,z -v /var/jenkins_home/workspace/declarative-pipeline@tmp:/var/jenkins_home/workspace/declarative-pipeline@tmp:rw,z -e ******** alpine:latest cat
docker run -t -d -u 1000:1000 -w /var/jenkins_home/workspace/declarative-pipeline@2 -v /var/jenkins_home/workspace/declarative-pipeline@2:/var/jenkins_home/workspace/declarative-pipeline@2:rw,z -v /var/jenkins_home/workspace/declarative-pipeline@2@tmp:/var/jenkins_home/workspace/declarative-pipeline@2@tmp:rw,z -e ******** alpine:latest cat
ocker run -t -d -u 1000:1000 -w /var/jenkins_home/workspace/declarative-pipeline@3 -v /var/jenkins_home/workspace/declarative-pipeline@3:/var/jenkins_home/workspace/declarative-pipeline@3:rw,z -v /var/jenkins_home/workspace/declarative-pipeline@3@tmp:/var/jenkins_home/workspace/declarative-pipeline@3@tmp:rw,z -e ******** alpine:latest cat
Структура папок рабочей области
Вау, я не знал об этом. Спасибо за понимание. Это мне очень поможет.
вы можете настроить свое рабочее пространство с помощью ws Jenkins dsl или очистить свое рабочее пространство в post dsl с помощью deleteDir(), так что оно будет очищаться, даже если конвейер извлечет ваш исходный код в каталог рабочей области jenkins по умолчанию.