Answers: <p>I guess you can do it via <code>rules</code> keyword. It has multiple condition with environment variables or branch name or schedules. If you add detail about you want to do, i try to</p>
  <p><a href="https://docs.gitlab.com/ee/ci/yaml/#rules" rel="nofollow noreferrer">Gitlab CI Rules</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2021-02-13T14:50:52.100Z
Answers: 2021-02-13T14:50:52.100Z
Answers: yusuf kocaman
Answers: <p>Yes, you can use the <a href="https://docs.gitlab.com/ee/ci/yaml/#rules" rel="noreferrer">rules</a> syntax. You can use this in combination with regex for commit message, <a href="https://docs.gitlab.com/ee/ci/yaml/#common-if-clauses-for-rules" rel="noreferrer">ci_pipeline_source</a> or any other available CI variables.</p>
  <pre><code>
  job1:
    script: 
      - do something on schedule only
    rules:
      - if: '&quot;$CI_PIPELINE_SOURCE&quot; == &quot;schedule&quot;'
        when: always
  
  job2:
    script: 
      - runs on Merge request pipeline
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: always
      when: never
  
  job2:
    script: 
      - runs on changes to anything in src directory or Dockerfile
    rules:
      - changes:
          - src/*
          - Dockerfile
  
  </code></pre>
  <p>Note you can also <a href="https://docs.gitlab.com/ee/ci/yaml/includes.html" rel="noreferrer">include</a> multiple CI templates in your gitlab-ci.yml. Additonally, you can include a CI template with <a href="https://docs.gitlab.com/ee/ci/yaml/#hide-jobs" rel="noreferrer">&quot;hidden&quot;</a> job templates that you can reference with <a href="https://docs.gitlab.com/ee/ci/yaml/#extends" rel="noreferrer">extends</a>:</p>
  <pre><code># Include ci files 
  include:
   - local: '/templates/.scheduled-job-template.yml' # CI template with hidden job (.scheduled_job) that runs on schedule
   - local: '/templates/.lint-and-validate.yml' # contains jobs for linting and validating project
  
  job1:
    extends:
      - .scheduled_job
    rules:
      - if: '&quot;$CI_PIPELINE_SOURCE&quot; == &quot;schedule&quot;'
        when: always
  
  job2:
    script: 
      - runs on Merge request pipeline
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: always
      when: never
  </code></pre>
  <p>In doing this you can compose the jobs/pipelines you want in its own yml file and then define the jobs using those templates in the gitlab-ci.yml, which will help keep things maintainable and clear if you are running numerous different pipeline/pipeline configurations from the same project.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-02-13T18:52:17.217Z
Answers: 2021-02-13T18:57:48.467Z
Answers: 2021-02-13T18:57:48.467Z
Answers: zm31
Body: <p>I know that I can't have multiple gitlab-ci.yml files in one repo, but it still seems fairly limited. Say for example I have one set of tests I want to run whenever a change is pushed or on PRs, and another set I want to run every 24 hours. Is there a way to do that, or do I only get one set of tests I have to use whenever I want to run CI?</p>
  
Tags: <continuous-integration><gitlab><continuous-deployment><gitlab-ci-runner>
Title: Can I run multiple pipelines in a single GitLab repo using GitLab CI/CD?
UserDisplayName: Christian Legge
ThreadText: # Can I run multiple pipelines in a single GitLab repo using GitLab CI/CD?
  
  (Asked by: username_0 on 2021-02-12)
  
  I know that I can't have multiple gitlab-ci.yml files in one repo, but it still seems fairly limited. Say for example I have one set of tests I want to run whenever a change is pushed or on PRs, and another set I want to run every 24 hours. Is there a way to do that, or do I only get one set of tests I have to use whenever I want to run CI?
  
  **Tags:** continuous-integration, gitlab, continuous-deployment, gitlab-ci-runner
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-02-13. Score: 14 | Accepted answer
  
  Yes, you can use the [rules](https://docs.gitlab.com/ee/ci/yaml/#rules) syntax. You can use this in combination with regex for commit message, [ci\_pipeline\_source](https://docs.gitlab.com/ee/ci/yaml/#common-if-clauses-for-rules) or any other available CI variables.
  
  ```
  
  job1:
    script: 
      - do something on schedule only
    rules:
      - if: '"$CI_PIPELINE_SOURCE" == "schedule"'
        when: always
  
  job2:
    script: 
      - runs on Merge request pipeline
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: always
      when: never
  
  job2:
    script: 
      - runs on changes to anything in src directory or Dockerfile
    rules:
      - changes:
          - src/*
          - Dockerfile
  
  ```
  
  Note you can also [include](https://docs.gitlab.com/ee/ci/yaml/includes.html) multiple CI templates in your gitlab-ci.yml. Additonally, you can include a CI template with ["hidden"](https://docs.gitlab.com/ee/ci/yaml/#hide-jobs) job templates that you can reference with [extends](https://docs.gitlab.com/ee/ci/yaml/#extends):
  
  ```
  # Include ci files 
  include:
   - local: '/templates/.scheduled-job-template.yml' # CI template with hidden job (.scheduled_job) that runs on schedule
   - local: '/templates/.lint-and-validate.yml' # contains jobs for linting and validating project
  
  job1:
    extends:
      - .scheduled_job
    rules:
      - if: '"$CI_PIPELINE_SOURCE" == "schedule"'
        when: always
  
  job2:
    script: 
      - runs on Merge request pipeline
    rules:
      - if: $CI_MERGE_REQUEST_ID
        when: always
      when: never
  
  ```
  
  In doing this you can compose the jobs/pipelines you want in its own yml file and then define the jobs using those templates in the gitlab-ci.yml, which will help keep things maintainable and clear if you are running numerous different pipeline/pipeline configurations from the same project.
  
  
  ---
  
  ### Answer by username_1 on 2021-02-13. Score: 0
  
  I guess you can do it via `rules` keyword. It has multiple condition with environment variables or branch name or schedules. If you add detail about you want to do, i try to
  
  [Gitlab CI Rules](https://docs.gitlab.com/ee/ci/yaml/#rules)
  
  
  ---
  
  