Понимание шагов конвейера Jenkins с помощью агента докера - PullRequest
0 голосов
/ 25 октября 2018

Я пытаюсь настроить автоматическое задание сборщика / развертывания с использованием конвейеров Jenkins.

У меня настроен докер-контейнер, устанавливающий зависимости NodeJS и Gulp:

Dockerfile

# Node 8.9 running on lean version of alpine Linux
FROM node:8.9-alpine

# Commented out setting production since 
# we need devDependencies to build
# ENV NODE_ENV production

# Set working directory to root of container
WORKDIR /

# Copy package.json and install dependencies first
# These can be cached as a step so long as they haven't changed
COPY ["./package.json", "./package-lock.json*", "/"]
RUN npm install --no-audit --silent
RUN npm install node-sass --silent
RUN npm install gulp-cli --silent
RUN npm install gulp@3.9 --silent

# Copy code to root, thise is a separate step from
# dependencies as this step will not be cached since code
# will always be different
COPY . .

# Debugging information
RUN ls
RUN pwd
RUN ./node_modules/.bin/gulp --version

Целью Dockerfile является кэширование установки зависимостей, чтобы задания сборки могли выполняться быстрее.

Jenkinsfile использует Dockerfile, а затем пытается запустить скрипт сборки npm

Jenkinsfile

pipeline {
  agent {
    dockerfile true
  }
  stages {
    stage('Compile static assets') {
      steps {
        sh 'node --version'
        sh 'npm --version'
        sh 'pwd'
        sh 'ls'
        sh 'npm run build'
      }
    }
  }
}

При запуске конвейера Jenkins инициализация (при которой Dockerfile используется и выполняется), похоже, не совпадает с шагами.См. Pwd и ls каждого:

Вывод с первого шага, на котором настроен контейнер

Step 9/10 : RUN ls

 ---> Running in 74b7483a2467


AO18_core

Jenkinsfile

bin

dev

dev_testing

etc

gulpfile.js

home

lib

media

mnt

node_modules

opt

package-lock.json

package.json

proc

root

run

sbin

srv

sys

tmp

usr

var

Removing intermediate container 74b7483a2467

 ---> e68a07c2bb45

Step 10/10 : RUN pwd

 ---> Running in 60a3a09573bc

/

Вывод с этапа Компиляция статических активов

[ao_test-jenkins-YCGQYCUVORUBPWSQX4EDIRIKDJ72CXV3G5KXEDIGIY6BIVFNNVWQ] Running shell script

+ pwd

/var/lib/jenkins/workspace/ao_test-jenkins-YCGQYCUVORUBPWSQX4EDIRIKDJ72CXV3G5KXEDIGIY6BIVFNNVWQ

[ao_test-jenkins-YCGQYCUVORUBPWSQX4EDIRIKDJ72CXV3G5KXEDIGIY6BIVFNNVWQ] Running shell script

+ ls

AO18_core

Dockerfile

Jenkinsfile

README.md

dev_testing

docker-compose.debug.yml

docker-compose.yml

gulpfile.js

jsconfig.json

package.json

Итак, в контексте выполнения, похоже, есть что-то неясное.Я предполагал, что после инициализации контейнера Docker весь конвейер будет выполняться в этом существующем контексте.Похоже, что это не так.

В настоящий момент у меня есть только один этап, но в итоге у меня будет несколько этапов для запуска, тестирования и развертывания.Надеемся, что все эти этапы будут выполняться в одном контексте.

1 Ответ

0 голосов
/ 26 октября 2018

Даже если вы измените WORKDIR в Dockerfile, Jenkins будет использовать назначенное рабочее пространство внутри контейнера, как при запуске сборки в обычном агенте.

Вы можете использовать опцию customWorkspace внутриопределение агента для изменения этого:

pipeline {
  agent {
    dockerfile {
      customWorkspace '/test'
      filename 'Dockerfile'
    }
  }
  stages {
    stage('Compile static assets') {
      steps {
        sh 'node --version'
        sh 'npm --version'
        sh 'pwd'
        sh 'ls'
        sh 'npm run build'
      }
    }
  }
}

Кроме того, вы можете использовать Генератор директив в разделе Синтаксис конвейера задания конвейера для получения конфигурации agent.

Дополнительная информация:https://jenkins.io/doc/book/pipeline/syntax/#common-options

...