Designing Jenkins CI/CD Pipelines for GitLab Push and Merge Scenarios

Author Zeyang, a DevOps engineer with 4‑5 years of experience, shares practical DevOps knowledge including CI/CD, programming, monitoring, and logging.

1. Introduction – a brief personal note referencing a movie and a light‑hearted comment.

2. Pipeline Trigger Scenarios – recommends building pipelines that start from version‑control events so each commit is automatically built, tested, and feedback is sent to the author.

Push Pipeline Design – describes configuring a Jenkins job to be triggered by a generic webhook, setting a unique token, filtering merge‑request and open events, and extracting branch and user information from GitLab payload.

Key steps include:

Submit‑and‑build: build on each commit, run compilation, unit tests, packaging, and code‑quality checks.

Immediate notification of build errors to the committer.

Merge Pipeline Design – outlines two designs. The first uses Jenkins to compile, test, and comment results on the merge request, notifying success or failure. The second leverages GitLab CI to enforce that a pipeline must succeed before a merge, updating commit status to success or failure accordingly.

Conclusion – multiple ways exist to implement pipelines; the author combined both push and merge pipelines into a single Jenkinsfile using when conditions to differentiate operations.