Alright, fellow automation nerds, I need to confess something. I was hoarding a Jenkins setup that was older than some of the martech tools in my stack. 😅 The worst offender? These massive, unreadable `email-ext` templates for build notifications. Hundreds of lines of Groovy script, nested conditionals, and brittle HTML that looked like it was from 2010.
We were migrating to GitLab CI and I saw my chance. Instead of porting over the monster, I replaced the entire complex template with a simple Python script that lives in our repo. The goal: clean, actionable notifications that our actual marketing ops team would read.
Here's the pain-to-simple breakdown:
**The Old Jenkins "email-ext" Way:**
* A single, monolithic `global_email_template.groovy` file in Jenkins.
* Hardcoded environment logic (`if (env == 'staging')`).
* Inline CSS (a mess).
* Required a Jenkins admin to change any wording or logic.
**The New GitLab CI Way:**
* A 120-line Python script (`scripts/notify_build_status.py`) in our project root.
* Uses environment variables passed from the `.gitlab-ci.yml` file for everything.
* Outputs clean, plaintext and HTML with clear sections: What broke, in which environment, a link to the pipeline, and the last 5 lines of the error log.
* Sends via a simple SMTP call (could swap for Postmark, SendGrid, etc.).
The migration took about two days, mostly spent testing the output formats and making sure the failure detection logic was solid. The real win? Now the *team* owns the notification logic. If we want to change the message or add a new detail, it's a code change in our own repo, not a Jenkins config hunt.
**Key pieces we pass from the pipeline:**
- `CI_PROJECT_NAME`
- `CI_ENVIRONMENT_NAME`
- `CI_JOB_STATUS`
- `CI_PIPELINE_URL`
- A snippet of the job log (captured via `tail`)
It's like replacing a monolithic, all-in-one martech suite with a best-of-breed stack. You get flexibility, clarity, and control. Has anyone else done a similar "de-monolithing" of their CI/CD notification system? What did you move to?
one stack at a time
Oh, this resonates on a deep, painful level. I've seen those same monstrous templates living in Jenkins for years, a huge risk because the one person who understood the logic left in 2018. 😅
Your move to a script in the repo is exactly right. I'd add one critical lesson from a similar migration I led: you now own the notification's entire lifecycle - including testing it. My team learned the hard way to write a small smoke test for that Python script. We'd run it locally with a fake JSON payload to make sure the HTML didn't break before it hit production pipelines. Saved us from a few "oops, all garbled text" emails to the whole department.
The other win is that you can now version control the notification logic alongside the project it serves. No more begging a platform team to tweak a Groovy conditional.
Implementation is 80% process, 20% tool.
You're still overcomplicating it. You moved from a Groovy monster to a Python script, but you're still writing custom HTML.
Just call a notification API. Slack, Teams, whatever your team actually reads. A 5-line curl command in your CI step. No CSS, no versioning, no testing.
Every line of custom notification code is a line you'll have to fix when the formatting breaks. Again.
Simplicity is the ultimate sophistication