Декларативный конвейер Jenkins - SCM

Я беру учебник Дженкинса. Я читал пример кода:

 pipeline {
    agent none
    stages {
        stage('Build') {
            agent {
                docker {
                    image 'python:2-alpine'
                }
            }
            steps {
                sh 'python -m py_compile sources/add2vals.py sources/calc.py'
            }
        }
        stage('Test') {
            agent {
                docker {
                    image 'qnib/pytest'
                }
            }
            steps {
                sh 'py.test --verbose --junit-xml test-reports/results.xml sources/test_calc.py'
            }
            post {
                always {
                    junit 'test-reports/results.xml'
                }
            }
        }
        stage('Deliver') { 
            agent {
                docker {
                    image 'cdrx/pyinstaller-linux:python2' 
                }
            }
            steps {
                sh 'pyinstaller --onefile sources/add2vals.py' 
            }
            post {
                success {
                    archiveArtifacts 'dist/add2vals' 
                }
            }
        }
    }
}

Итак, в основном есть три шага Build, Test и Deliver. Все они используют разные изображения для создания разных контейнеров. Но это задание Jenkins настроено на использование Git в качестве SCM.

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

Насколько я понимаю, каждый этап должен выполняться git clone/git pull, а до его завершения требуется git push.

Если SCM IS настроен через Jenkins для использования Git, нужно ли нам включать функцию Jenkins git clone/git pull', as well as 'git push' in the corresponding shell scripts(understeps, or it it already taken into consideration by theSCM`?

Спасибо


person Community    schedule 02.01.2019    source источник


Ответы (1)


В этом случае вы должны убедиться, что двоичный файл, который находится в среде QA, должен быть таким же, каким он должен быть в среде UAT, а затем в рабочей среде. Для этого вы должны использовать репозиторий артефактов или реестр (Artifactory, Nexus, Docker Registry и т. Д.) Для продвижения артефактов в производственную среду. См. Эту ссылку и узнайте, как это было сделано в конвейере.

person dalmo.santos    schedule 04.01.2019