Comprehensive GitLab CI/CD Job Templates and Default Pipeline for Java Projects

The article explains how to organize CI/CD job templates in a GitLab project, using a default-pipeline.yml as the foundational template for all jobs.

Job templates are stored in a jobs directory and include separate YAML files for build, test, code analysis, artifact management, and deployment. Each template uses a rules switch controlled by variables to enable or disable the job.

.build:
  stage: build
  script:
    - | ${BUILD_SHELL}
  variables:
    GIT_CHECKOUT: "true"
  rules:
    - if: " $RUN_PIPELINE_BUILD == 'no' "
      when: never
    - when: always

.build-docker:
  stage: buildimage
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWD $CI_REGISTRY
    - docker build -t ${IMAGE_NAME} -f ${DOCKER_FILE_PATH} .
    - docker push ${IMAGE_NAME}
    - docker rmi ${IMAGE_NAME}
  rules:
    - if: " $RUN_BUILD_IMAGE == 'no' "
      when: never
    - when: always

The test job runs unit tests (Maven/Gradle/NPM) and publishes JUnit reports.

.test:
  stage: test
  script:
    - $TEST_SHELL
  artifacts:
    reports:
      junit: ${JUNIT_REPORT_PATH}
  rules:
    - if: " $RUN_PIPELINE_TEST == 'no' "
      when: never
    - when: always

Code analysis uses SonarQube, defining global project, server, and merge‑request arguments, and conditionally runs the scanner based on branch or merge‑request context.

.code_analysis:
  stage: code_analysis
  image: ${SONAR_IMAGE}
  script:
    - echo ${GLOBAL_PROJECT_ARGS} ${GLOBAL_SERVER_ARGS} ${SONAR_SCAN_ARGS} ${GLOBAL_MR_ARGS}
    - sonar-scanner ${GLOBAL_PROJECT_ARGS} ${GLOBAL_SERVER_ARGS} ${SONAR_SCAN_ARGS}
  rules:
    - if: " $RUN_CODE_ANALYSIS == 'no' "
      when: never
    - when: always

Artifact upload and download jobs interact with an Artifactory repository using curl commands.

.deploy-artifact:
  stage: deploy-artifact
  script:
    - curl -u${ARTIFACT_USER}:${ARTIFACT_PASSWD} -T ${ARTIFACT_PATH} "$ARTIFACTORY_URL/$ARTIFACTORY_NAME/$TARGET_FILE_PATH/$TARGET_ARTIFACT_NAME"
  rules:
    - if: " $RUN_DEPLOY_ARTIFACTS == 'no' "
      when: never
    - when: always

.down-artifact:
  stage: down-artifact
  script:
    - curl -u${ARTIFACT_USER}:${ARTIFACT_PASSWD} -O "$ARTIFACTORY_URL/$ARTIFACTORY_NAME/$TARGET_FILE_PATH/$TARGET_ARTIFACT_NAME"
    - ls

Deployment jobs use kubectl to apply Kubernetes manifests, create Docker registry secrets, and support manual rollout and rollback for feature, UAT, staging, and production environments.

.deploy_k8s:
  stage: deploy
  script:
    - kubectl config set-cluster my-cluster --server=${KUBE_URL} --certificate-authority="${KUBE_CA_PEM_FILE}"
    - kubectl config set-credentials admin --token=${KUBE_TOKEN}
    - sed -i "s#__namespace__#${NAMESPACE}#g" ${DEPLOY_FILE}
    - sed -i "s#__appname__#${APP_NAME}#g" ${DEPLOY_FILE}
    - kubectl apply -f ${DEPLOY_FILE}
  rules:
    - if: " $RUN_DEPLOY_K8S == 'no' "
      when: never
    - when: manual
  environment:
    name: "${ENV_NAME}"
    url: "http://${ENV_NAME}.${CI_PROJECT_NAMESPACE}.${CI_PROJECT_NAME}.devops.com"

.rollout_k8s:
  stage: rollout
  script:
    - kubectl rollout undo deployment ${APP_NAME} -n ${NAMESPACE}
  rules:
    - if: " $RUN_DEPLOY_K8S == 'no' "
      when: never
    - when: on_failure
  environment:
    name: "${ENV_NAME}"
    action: stop

The default-pipeline.yml template is divided into four main sections:

Include: imports the job templates from the jobs directory.

Variables: defines global variables for repository paths, job control flags, container images, build/test parameters, SonarQube settings, Docker registry details, artifact repository configuration, and Kubernetes deployment values.

Workflow: sets rules to filter merge requests, web triggers, release or master branches, and branch creation events, with a default always‑run policy.

Jobs: declares stages (build, test, parallel01, get_analysis_result, deploy‑artifact, deploy‑feature, rollout‑feature, deploy‑uat, rollout‑uat, deploy‑stag, rollout‑stag, deploy‑prod, rollout‑prod) and configures each job using the extends keyword to inherit the templates defined earlier.

For a Java project, the pipeline can be imported with an include statement pointing to templates/default-pipeline.yml, and project‑specific variables are set to enable or disable each stage (e.g., RUN_PIPELINE_BUILD="yes", RUN_DEPLOY_K8S="yes"). The pipeline then executes the defined stages, builds Docker images, runs SonarQube analysis, uploads artifacts, and deploys the application to a Kubernetes cluster with manual approval steps for each environment.