Skip to content

Branch Rules & Workflow

Which pipeline stages run on which branches, how to trigger manual deployments, and how to use GitLab's pipeline API to control CI/CD behaviour without pushing code.

Workflow Rules Summary

The .gitlab-ci-common.yml template defines workflow: rules that control when a pipeline runs and what it does. The rules are evaluated top-to-bottom; the first match wins.

Branch / Trigger Pipeline Runs Auto Deploy to DEV SonarQube Scan Docker Image Scan DefectDojo Import
main Full pipeline Yes (automatic) Yes Yes Yes
feature/* validate + test + build No (manual job available) No No No
develop Full pipeline Yes (automatic) No No No
release/* Full pipeline No (DEMO deploy — manual) No No No
Version tag (v*) Release stage only No No No No
DEPLOY_ONLY=true (any branch) deploy-dev + verify only Yes (automatic) No No No

MR pipelines are disabled

Merge request event pipelines (merge_request_event) are disabled in the workflow rules. Testing and validation happen on the source branch before the MR is opened, not on the merge ref. This avoids running duplicate pipelines.

Branch Strategy

CWIQ uses trunk-based development. main is the stable trunk and is always deployable. All work happens on short-lived feature branches.

gitGraph
    commit id: "initial"
    branch feature/server-search
    checkout feature/server-search
    commit id: "add search API"
    commit id: "add tests"
    checkout main
    merge feature/server-search id: "MR !42"
    commit id: "auto-deploys to DEV"

Feature branches (feature/*) run only the validate, test, and build stages. This gives fast feedback without triggering a deployment. When the feature branch is ready, open an MR to main. After merge, the main pipeline runs the full pipeline and deploys automatically to DEV.

Manual Pipeline Triggers

Trigger a Deploy-Only Pipeline

Use this when you need to redeploy the last built image without running validate, test, or build again. This is useful after a config change on the server or after a quick fix to an infrastructure setting.

TOKEN="your-personal-access-token"

# Replace 5 with the target project ID (see Groups & Projects page)
curl -s -X POST "https://gitlab.shared.cwiq.io/api/v4/projects/5/pipeline" \
  --header "PRIVATE-TOKEN: $TOKEN" \
  -F "ref=main" \
  -F "variables[DEPLOY_ONLY]=true"

When DEPLOY_ONLY=true is set, the pipeline skips all stages except deploy-dev and verify. The deploy job reads IMAGE_TAG from the most recent successful build artifact.

Trigger a Full Pipeline

Trigger a full pipeline run on main without pushing a commit — useful after updating a CI/CD variable or secret in Vault.

curl -s -X POST "https://gitlab.shared.cwiq.io/api/v4/projects/5/pipeline" \
  --header "PRIVATE-TOKEN: $TOKEN" \
  -F "ref=main"

Trigger a Manual Deploy Job

When a pipeline has already run but the deploy job was set to manual (MANUAL_DEPLOY=true), use the jobs API to play it:

# First, find the job ID
curl -s "https://gitlab.shared.cwiq.io/api/v4/projects/5/pipelines/{PIPELINE_ID}/jobs" \
  --header "PRIVATE-TOKEN: $TOKEN" | \
  python3 -c "import sys,json; [print(j['id'], j['name'], j['status']) for j in json.load(sys.stdin)]"

# Then play the job
curl -s -X POST "https://gitlab.shared.cwiq.io/api/v4/projects/5/jobs/{JOB_ID}/play" \
  --header "PRIVATE-TOKEN: $TOKEN"

Retry a Failed Pipeline

curl -s -X POST "https://gitlab.shared.cwiq.io/api/v4/projects/5/pipelines/{PIPELINE_ID}/retry" \
  --header "PRIVATE-TOKEN: $TOKEN"

Checking Pipeline and Job Status

List Recent Pipelines for a Project

curl -s "https://gitlab.shared.cwiq.io/api/v4/projects/5/pipelines?per_page=5" \
  --header "PRIVATE-TOKEN: $TOKEN" | \
  python3 -c "
import sys, json
for p in json.load(sys.stdin):
    print(p['id'], p['status'], p['ref'], p['created_at'])
"

Get Job Logs (Last 100 Lines)

curl -s "https://gitlab.shared.cwiq.io/api/v4/projects/5/jobs/{JOB_ID}/trace" \
  --header "PRIVATE-TOKEN: $TOKEN" | tail -100

Feature Branch Deploy (Manual)

Feature branch pipelines do not deploy automatically. If you need to test a feature branch on the DEV server, the deploy-dev job exists on feature branches but is set to when: manual. Click the play button in the GitLab pipeline UI to trigger it, or use the jobs API above.

Feature branch deploys overwrite the DEV environment

The DEV environment is a shared environment. Deploying a feature branch will replace whatever was previously deployed. Coordinate with the team before deploying a feature branch to DEV. After testing, merge your branch and let the main pipeline restore the canonical DEV state.