I’m in progress of replacement Jenkins with GitLab, I have a few shared Jenkins libraries, I wonder what is the best way to implement the shared library (some piece of code that is used in the multiple repositories) in GitLab?
My shared library contains at least two “global” pipelines - they can be split to the two .gitlab-ci.yml files.
I’ve read about include with file option:
And it looks like very close to what I need, but the same time I see child pipelines, that use trigger keyword with include.
Correct me if I am wrong, but in case of include - we just inline the code from the file, in case of trigger - it just runs a separate downstream pipeline. Are there any recommendations to use one or another? Any pitfalls?
I’m not familiar with shared libraries in Jenkins, but after reading Extending with Shared Libraries it feels like a central Git repository where you’ll organize CI/CD config templates, additional tool configs, and otherwise scripts and tools to copy/download into jobs.
Start with creating an new template project and add a .gitlab/ci/ directory (path is freely definable, following .gitlab/ci · master · GitLab.org / GitLab · GitLab here.
Next, create a test project which includes the template. Recommend using the Pipeline Editor to verify the config syntax as well as see merged results.
If that approach works well, establish a file structure for common tools. It may also work well with adding Dockerfile templates, and build your own base images with build tools pre-installed. That avoids the regular download in CI jobs. Examples are gcc as compiler, package tool chains, etc.
The template project may not be enough, maybe it needs a group of projects maintained by different teams. Discuss the approach with your teams too
Thank you for reply, @dnsmichi, I faced an issue while implementing this case in GitLab with templates and child builds.
The bug is in parent-child variables precedence.
