添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

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

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?

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.png 1058×99 13.6 KB

    @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! :blush:

    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.

    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?

    Multiple .gitlab-ci.yaml files per repository that run different pipelines How to Use GitLab I think this is possible with generated includes. Basically, you can create an artifact file that is your “child” gitlab CI config file. Then you can reference the artifact in your trigger. More information here

    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.