Git CI/CD job depending on merged branch

Question

Good morning I need to execute different git CI/CD scripts depending on what branch I’ve merged. I don’t know if it’s possible and I don’t know how to start. I’ve a repository of a visual studio solution that contains 3 projects. I’d like to publish only one project at time. I’m thinking to create 3 branch: publishProject1, publishProject2 and publishProject3. When I merge all the solution into publishProject1 only projects 1 must be published and when I merge all the solution in publishProject2 only project 2 must be published etc. Is this the right way to do? Thanks for the help

UPDATE I've tried to edit .gitlab-ci.yml like this

    stages:
    - build1
    - build2


build1:
    stage: build1

    rules:
        - if: $CI_PIPELINE_SOURCE == 'merge_request_event' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'PublishProject1'

    script:
    #do the script for pubblish project1

build2:
    stage: build2

    rules:
        - if: $CI_PIPELINE_SOURCE == 'merge_request_event' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'PublishProject2'

    script:
    #do the script for pubblish projec2

This work if i merge into PubblishProject1 but doesn't work if i merge in PubblishProject2.

Thanks for your help

Answer 1

It starts by creating a .gitlab-ci.yml file^TUT and it sounds like that you want to have different jobs (all with their scripts) and have them run conditionally by rules ¹. Predefined CI/CD variables enable you to translate your outlined workflow from your own language into such rules.

For getting started I'd actually create three jobs to publish the three projects, all with their own script and rule each, even if those three are similar.

The key point is to get started and get it functional, as the main part is not to optimize it, but to understand which variables are needed, how they work, how they interact with the rules and the scripts.

Once you have it set up and working, it is easier to reason whether or not the workflow is well-designed. And as the CI build is well-defined and committed already, any later change is already version controlled, so you can treat it as a change request within your software configuration management.

---

1. "List of conditions to evaluate and determine selected attributes of a job, and whether or not it’s created." (ebd.)