Multiple pipelines for same repo

I understand the pipeline is defined via the gitlab-ci.yml file.
So this would mean there can only be one pipeline per repo?
Is it possible to have more than one, if so, how?

Thanks

Hello!
I have the same situation. I tried different ways but got this:

I can’t find nothing about it in documentation.

My situation is:
There are projects, ex. proj1 and proj2 with the same code base.
But proj2 has some differences, ex. logo and haven’t tests.
When building proj2 i change only logo and add tests.

I want to get something like this:

Have you any progress of your problem?

Basically, you can specify which branch you want a stage to run on by doing

only:

• branchABC

In this case, this stage would only run when something pushed to branch called branchABC

You can do so.
The same without branches.
I solved the problem in this way. I have created several stages:

`stages:

• build_proj1
• test_proj1
• deploy_proj1
• build_proj2
• deploy_proj2`

Screen Shot 2016-10-03 at 11.17.35.png1058×99 13.6 KB

@Mikasa unfortunately, that doesn’t seem scalable. What if i’ll have 10+ microservices?

@Mikasa Have you find a solution for your problem ? How did you solve it ?

Unfortunately, no.
We moved to our own CI/CD system.

@iRaJaaa - Since this thread is pretty old, I would love to hear your specific use case, and what unexpected behavior you are seeing. Especially since the original poster has since moved on. (Thanks for coming back to give an answer, @Mikasa!)

Eager to help troubleshoot this with you!

Hello @Linds, thank you for your message.

That’s my specific use case :

I have 2 projects in my Gitlab with the same code base. I mean that the first one could be like a master and the second one the dev/test (I know it’s similar than a branch, but that’s my organization.)

So the idea is that in the project 2, I would like to test it (syntax control, build it in a container, and then deploy on the container), if it’s works, then I would like to do like a “merge request” to the project 1 and finally push the content of project 2 on projet 1 because the test is successful on project 2. That’s a example of my use case.

@Mikasa @johntest Have you got some information about my last request ?

Another use case:
We have deployment scripts for different projects in one repo.
We would like to have

• pipeline1 to deploy proj1
• pipeline2 to deploy proj2
  -…
  Let’s say we start manually the required pipeline.

My use case is to have ordinary pipeline that kicks in on each commit, and an extra pipeline (could be a different ci yaml file easily) that kicks in daily schedule. So I can publish daily builds or run more heavy jobs once a day, and not on every commit.
Now I have to make a branch and replace .gitlab-ci.yml and schedule that branch, but then I have to rebase it daily… isn’t there any better way to solve this?

I have a machine learning project that has a need to have 2 pipelines. One to train the ML model and stored the model in a model repo. The other to load the trained model from model repo and expose it as a service through REST API. Let’s names these as training and inference pipelines. I want to run these pipelines independently using two pipelines based on which files changes. For example, if training dataset change, kick off the ‘training’ pipeline and if the API response format changes, kick off the ‘inference’ pipeline. Wondering if this can be done using two .gitlab-ci.yml files or is there a way to do it with a single file?

So I asked the same question here and found a solution:

Basically, direct from the Gitlab docs, you can run a build step that generates a gitlab ci configuration file and saves it as an artifact. You can so anything you want in this script, so you can pass in variables set as gitlab ci variables. Then, you can include the generated gitlab ci config file artifact.

generate-config:
  stage: build
  script: generate-ci-config > generated-config.yml
  artifacts:
    paths:
      - generated-config.yml

child-pipeline:
  stage: test
  trigger:
    include:
      - artifact: generated-config.yml
        job: generate-config

I then use a trigger to trigger the workflow with variables that generate a different config file.

This is not viable for everyone, but you could have multiple tags on the same commit. Each tag triggering different pipelines.

back after 8 years! cool to see all the responses.
i honestly don’t remember what I did with that project

You can totally have multiple pipelines in a single repo by using different YAML files or defining multiple jobs within the same file and specifying different conditions or triggers for them.

This is achievable now with Downstream Pipelines: Downstream pipelines | GitLab and combining with workflow/job rules.