If you have (or not) writed GitLabCI pipelines, let me speak you about parent-child pipelines. It's something very simple to understand, and very simple to implement in your (future) project. 🥳
Imagine you have several components on your application (at min one front end, one back end). In my exemple i have two front-end and three back-end. My .gitalb-ci.yml file contains approximately one hundred lines, with tests execution, build, create and push docker images on the GitLab registry. I haven't implemented yet a deploiement on a cloud or one physical machine.
My pipeline is executed when one modification is maked on a file, whether it be on one front-end, or one back-end. All my test, all my images docker are build, even if i did't change one component.
Use parent-child pipelines have several goals :
1️⃣ to reduce the size of your .gitlabc-ci.yml file. It's allows to enhance your pipeline lisibility and each child pipeline will be easily understand
2️⃣ to reduce the execution time because your will execute the pipeline only on your component changed
3️⃣ to reduce again the pipeline time execution because the childs pipelines can be executed without wait all the precedents stages
So, if you have a big pipeline or if you want to add a lot of fonctionnality, it's time to use parent-child-pipeline ! ⏱
In your parent .gitlab-ci.yml file, you can define one stage, as for exemple trigger :
stages:
- triggers
Next, you can define one block code for each component which you have. And each one will be defined with the trigger stage. Therefore all child pipeline can be execute at the same time :
📦 front :
stage: triggers
trigger:
include: front/xxxx/.gitlab-ci.yml
Each component have henceforth one .gitlabc-ci.yml file. For example :
front :
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- echo $CI_COMMIT_REF_NAME"_"$CI_PIPELINE_ID > /kaniko/version.txt
- /kaniko/executor --context $CI_PROJECT_DIR/front/ --dockerfile $CI_PROJECT_DIR/front/Dockerfile --destination $CI_REGISTRY_IMAGE/front:$(cat /kaniko/version.txt)
only:
- master
You juste be careful with the path. if you want to work with your files, your need to specify the directory. Now the path is the root path, not the directory where you are.
A last thing about the parent .gitlab-ci.yml file, you can add rules, and the first one to know is changes which allows to execute the child pipeline when one files is change in the component. Don't forget this one ! In my case, this is the definition :
📦 front :
stage: triggers
trigger:
include: front/.gitlab-ci.yml
rules:
- changes:
- front/*
When i change one file in my front directory, you can see that my pipeline execute only the jobs of this child pipeline.
On the pipeline, you can see which part is a child pipeline. You can click on this one to see the jobs available in this.
Or you can click on the arrow to see the child pipeline.
You can see that you are in a child pipeline :
It's simple, easy to change your pipeline ! If you don't know this feature, go quicky change them, you can win time and economize energy ! 🤘 😁
You can find more informations in this page.
Top comments (6)
but when cancel parent pipeline, the child pipeline did not stoped . It's still running until completed or fail
Exactly, child have their own lifecycle. I didn't specify this
hmm, and do you have an solution when the parent pipeline have interruptible true, and the parent CAN BE CANCELED when the new push come up. Now, the parent canceled for the new one, but the child still running/pending. I'm working in this feature and stuck at here now
currently no. I have to work on this part
exists it a way to use more than 3 time "trigger"
Hi, not yet I think (and sorry for the delay in response).