docs: modular workflow rules

| `integ` | skipped on the [integration branch](#production-and-integration-branches) |

| `dev`   | skipped on any development branch (other than production or integration) |

This feature can be disabled by removing `!reference [.tbc-workflow-rules, extended-skip-ci]` from `worflow: rules: []`. See next section for more details.

## Merge Request workflow

One thing that has to be chosen with GitLab CI/CD is the [Merge Request workflow strategy](https://docs.gitlab.com/ci/yaml/workflow/#switch-between-branch-pipelines-and-merge-request-pipelines).

By default, _to be continuous_ implements the **merge request pipelines** strategy, with the following workflow declaration:

```yaml

# use Merge Request pipelines rather than branch pipelines

workflow:

  rules:

# default workflow rules: Merge Request pipelines

.tbc-workflow-rules:

  # prevent MR pipeline originating from production or integration branch(es)

  skip-back-merge:

    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $PROD_REF || $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $INTEG_REF'

      when: never

  # on non-prod, non-integration branches: prefer MR pipeline over branch pipeline

  # ⚠️ can't be used with next rule

  prefer-mr-pipeline:

    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_COMMIT_REF_NAME !~ $PROD_REF && $CI_COMMIT_REF_NAME !~ $INTEG_REF'

      when: never

    # the 7 next rules implement the extended [skip ci] feature

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*tag(,[^],]*)*\]/" && $CI_COMMIT_TAG'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*branch(,[^],]*)*\]/" && $CI_COMMIT_BRANCH'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*mr(,[^],]*)*\]/" && $CI_MERGE_REQUEST_ID'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*default(,[^],]*)*\]/" && $CI_COMMIT_REF_NAME =~ $CI_DEFAULT_BRANCH'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*prod(,[^],]*)*\]/" && $CI_COMMIT_REF_NAME =~ $PROD_REF'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*integ(,[^],]*)*\]/" && $CI_COMMIT_REF_NAME =~ $INTEG_REF'

      when: never

    - if: '$CI_COMMIT_MESSAGE =~ "/\[(ci skip|skip ci) on ([^],]*,)*dev(,[^],]*)*\]/" && $CI_COMMIT_REF_NAME !~ $PROD_REF && $CI_COMMIT_REF_NAME !~ $INTEG_REF'

  # prefer branch pipeline over MR pipeline

  # ⚠️ can't be used with previous rule

  prefer-branch-pipeline:

    - if: $CI_MERGE_REQUEST_ID

      when: never

    # default: execute

  # extended "[skip ci]" behavior

  extended-skip-ci: [] # hidden for readability

  # TBC default rules (MR workflow policy)

  default:

    - !reference [.tbc-workflow-rules, skip-back-merge]

    - !reference [.tbc-workflow-rules, prefer-mr-pipeline]

    - !reference [.tbc-workflow-rules, extended-skip-ci]

workflow:

  rules:

    - !reference [.tbc-workflow-rules, default]

    - when: always

```

If you want to switch to the **branch pipelines** strategy, simply add the following to your `.gitlab-ci.yml` file:

```yaml

workflow:

  rules:

    # prevent Merge Request pipeline

    - if: $CI_MERGE_REQUEST_ID

      when: never

    # /!\ you MAY keep the 7 rules implementing the extended [skip ci] feature

    # >> here <<

    - !reference [.tbc-workflow-rules, skip-back-merge]

    - !reference [.tbc-workflow-rules, prefer-branch-pipeline]

    - !reference [.tbc-workflow-rules, extended-skip-ci]

    - when: always

```

> Use the latest version of each **_to be continuous_ templates** to be guaranteed to use this one, or else explicitly

> redefine the strategy you want in your `.gitlab-ci.yaml` file.

Using the same technique as above, you are free to adapt the Workflow Rules by removing or modifying generic _to be continuous_ rules or even adding your own custom rules. 

## Test & Analysis jobs rules

As explained [in this chapter](understand.md#development-workflow), by default _to be continuous_ implements an **adaptive pipeline** strategy with test & analysis jobs: