In my project I'd like to have two separate Gitlab CI/CD configurations, each for specific Gitlab instance. These file names could look like:
.gitlab-ci-1.yml
.gitlab-ci-2.yml
Is that possible to specify in the Gitlab which configuration file it should use instead of using default .gitlab-ci.yml?
Yes, this is possible. See Specify a custom CI/CD configuration file.
Related
I have a couple apps that use the same GCP project. There are dev, stage, and prod projects, but they're basically the same, apart from project IDs and project numbers. I would like to have a repo in gitlab like config where I keep these IDs, in a dev.tfvars, stage.tfvars, prod.tfvars. Currently each app's repo has a directory of config/{env}.tfvars, which is really repetitive.
Googling for importing or including terraform resources is just getting me results about terraform state, so hasn't been fruitful.
I've considered:
Using a group-level Gitlab variable just as key=val env file and have my gitlab-ci yaml source the correct environment's file, then just include what I need using -var="key=value" in my plan and apply commands.
Creating a terraform module that either uses TF_WORKSPACE or an input prop to return the correct variables. I think this may be possible, but I'm new to TF, so I'm not sure how to return data back from a module, or if this type of "side-effects only" solution is an abusive workaround to something there's a better way to achieve.
Is there any way to include terraform variables from another Gitlab project?
I am running my GitLab CI pipelines in an offline environment with none of my repositories containing the pipeline YAML files. Due to the sheer number of repositories I enabled AutoDevOps to use a baseline image until I can define pipelines for each specific repository as necessary, however, the application dependencies and pipeline images cannot be downloaded. I have a means to resolve this, but it requires configuration in the .gitlab-ci.yml file meaning the default AutoDevOps templates cannot be used and I have to make changes in every single repository, defeating the point of enabling AutoDevOps in the first place.
Is there a way to override the default AutoDevOps templates with my own?
From the documentation :
Auto DevOps is completely customizable because the Auto DevOps
template is just an implementation of a .gitlab-ci.yml file.
So AutoDevOps pipelines are only .gitlab-ci.yml files and you need to include them to overrides jobs and anything in this pipeline. You need to include a .gitlab-ci.yml file to override the default.
AutoDevOps is useful even if you include a ci file because it add a lot of jobs without writing them.
Present we kept multiple pipelines in separate yml files and all of them are included in the mail ci yml file.
using include statements.
Is there anyway to make it conditional.
Like I will have pipeline1 and pipeline2 yaml files.
So I can create another pipeline.yml where I can choose among the above two files based on some condition.
Gitlab is designed for deterministic pipelines, all other solutions add-on that looks implicit.
Web service
Include in .gitlab-ci.yml link to the web server, which could be a dynamically generated yml file.
include:
- 'https://your-service.com/gitlab-ci-generate'
Unfortunately, It's not possible to use CI variables in link to server. gitlab issue link
Dynamic child pipelines
You have complete control of the pipeline. Write a simple bash script, which renames your pre-pushed .yml files and executes that pipeline.
We have hundreds of similar projects in GitLab which have the same structure inside.
To build these projects we use a one common TeamCity build. We trigger and pass project GitLab URL along with other parameters to the build via API, so TeamCity build knows which exact project needs to be fetched/cloned. TeamCity VCS root accepts target URL via parameter.
The question is how to replace existing TeamCity build with a GitLab pipeline.
I see the general approach is to have CI/CD configuration file(.gitlab-ci.yml) directly in project. Since the structure of the projects the same this is not the option to duplicate the same CI/CD config file across all projects.
I'm wondering is it possible to create a common pipeline for several projects which can accept the target project URL via parameter ?
You can store the full CICD config in a repository and put in all your projects a simple .gitlab-ci.yml which includes the shared file.
With thus approach there is no redundant definition of the jobs.
Still, you can add specific other jobs to specific projects (in the regarding .gitlab-ci.yml files or define variables in a problem and use some jobs conditionally) - you can also include multiple other definition files, e.g. if you have multiple similar projects.
cf. https://docs.gitlab.com/ee/ci/yaml/#include
With latest GitLab (13.9) there are even more referencing methods possible: https://docs.gitlab.com/ee/ci/yaml/README.html#reference-tags
As #MrTux already pointed out, you can use includes.
You can either use it to include a whole CI file, or to include just certain steps. in Having Gitlab Projects calling the same gitlab-ci.yml stored in a central location - you can find detailed explanation with examples of both usages
I have an existing directory structure on a machine and want to configure Gitlab CI to clone/fetch repos to specific paths.
I've managed to change the builds_dir property in the config.toml file to start in the correct place, but Gitlab adds extra nested folders by default.
So I set:
builds_dir = "/Users/myUser/Development/projName"
and when Gitlab CI clones the repo, it adds
"/555555bb/0/orgName"
so I end up with:
"/Users/myUser/Development/projName/555555bb/0/orgName/projName"
Is there a way in the Gitlab config file to remove the extra sub-directories, or is my only option to move the files around after the clone/fetch is complete?
Because of how Gitlab runners work you need to copy the files to the appropriate locations.
Since runners can handle multiple projects, they need to differentiate them in some way and this is where /555555bb/0/orgName part comes in.
You can define in your project-specific runner config where those files need to be copied to (a simple copy command will suffice).
I solved it by creating a symbolic link between the repository used by the gitlab runner and the repository I am wishing to use for the deployment of the application.