CODEWITHSUNDEEP
gitlabgitlab-ci
Rom098
Rom098

Reputation: 2603

Run another GitLab repo's CI to validate a merge request

I've got a number of projects located in different GitLab repositories (repo1, repo2, ...). These projects can be built with the build scripts located in another repo (build_scripts).

The build_scripts contain YMLs, shell scripts, and other stuff, needed to create a GitLab pipeline with build and test jobs for each project.

GitLab CI/CD for each project is configured as the following, file .gitlab-ci.yml:

include:
  - project: 'build_scripts'
    ref: master
    file: '/general-pipeline.yml'

File general-pipeline.yml describes a pipeline containing build and test stages. The build stage contains several jobs building for different OS/arch. The test stage depends on build and runs test suites for every build in the current pipeline.

So, when creating MR to one of the projects in repo1, repo2, etc., GitLab creates a pipeline from build_scripts/general-pipeline.yml to validate this MR.

However, build_scripts itself needs to be modified sometimes, and I create MRs to build_scrips to integrate new changes.

Is it possible to validate build_scripts's MRs by building my projects with new changes before MR is integrated to build_scripts master branch?

In other words, I'd like to run CI for projects repo1, repo2, etc. on every build_scripts repo's MR specifying a particular branch to take build_scripts from.

Upvotes: 0

Views: 79

Answers (2)

Rom098
Rom098

Reputation: 2603

I've ended up with the following solution and it works pretty well for me.

The first, create the default YAML for projects/branches to make using build scripts flexible:

include:
  - project: $MY_SCRIPTS_PROJECT
    ref: $MY_SCRIPTS_REF
    file: '/gitlab/main.yml'

Then, through a project's "Settings - CI/CD - Variables" create project variables to set up default values:

MY_SCRIPTS_PROJECT = mygroup/build_scripts
MY_SCRIPTS_REF = master

So, for regular builds, /gitlab/main.yml will be taken (included) from master branch of mygroup/build_scripts project.

Please note, that these need to be project (or group) variables. If you try to create them at variables: section of your YAML, it won't work.

The second, in the build scripts repo, create the default YAML to test build scripts changes on merge requests:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

default:
  interruptible: true # doesn't affect downstream pipelines

variables:
  MY_SCRIPTS_PROJECT: $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH
  MY_SCRIPTS_REF: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME

myproject1-master sanity:
  stage: build
  variables:
    RUN_TEST: "test1"
  trigger:
    strategy: depend
    project: mygroup/myproject1
    branch: master

myproject2-dev1 sanity:
  variables:
    RUN_TEST: "test2"
  stage: build
  trigger:
    strategy: depend
    project: mygroup/myproject2
    branch: dev1

myproject1-master full:
  when: manual
  stage: build
  trigger:
    strategy: depend
    project: mygroup/myproject1
    branch: master

On every merge request to build scripts repo, this YAML will trigger downstream pipelines for master branch of mygroup/myproject1 and dev1 branch of mygroup/myproject2, passing to them merge request's source project path and branch to test if my projects can be built with the changes.

Additionally I've created a manual downstream pipeline, which is intended to perform full testing.

Upvotes: 0

ha36d
ha36d

Reputation: 1127

There isn't a feature for this, but here is the guideline:

After each change, build_scripts should be tagged on master, and on other branches, the tag version should be used. Because it avoid unwanted use of merged code into master. Therefore the code in build_scripts will be tagged by Semver (i.e v0.0.1), then in repo1, repo2, etc:

include:
  - project: 'build_scripts'
    ref: `v0.0.1`
    file: '/general-pipeline.yml'

When a new MR is created in build_scripts, it has a branch name (i.e feat-X1). A new MR can be created in repo1, repo2, etc to validate the stuff changed in build_scripts:

include:
  - project: 'build_scripts'
    ref: `feat-X1`
    file: '/general-pipeline.yml'

After being validated, it will be merged in build_scripts and tagged as v0.0.2. In the repo1, repo2 repositories, gradually the changes will be applied:

include:
  - project: 'build_scripts'
    ref: `v0.0.2`
    file: '/general-pipeline.yml'

Upvotes: 0

Related Questions