By Peter Miller · Published March 24, 2026 · Last updated: September 15, 2026
11 min read · Open the req, rewrite bullet one, rerun the checker
You've maintained pipelines, tuned runners, and merged YAML changes at 4 a.m. Your resume still opens with DevOps engineer skilled in CI/CD and cloud technologies. That's why platform reqs go quiet even when the GitLab tenure is real. The gap isn't missing buzzwords. It's that Greenhouse and Workday see duty language where they search for .gitlab-ci.yml, GitLab Runner, and pipeline stages on dated lines.
Before you rewrite bullet one, check your resume for free with the posting pasted in. You'll often see CI/CD flagged as matched while .gitlab-ci.yml, runners, and artifact caching never appear under your current title. GitLab CI resume keywords belong in Experience first, and Skills should echo them second.
Job searching in DevOps is draining. You're qualified. You're also competing with internal transfers who already speak the req's stack on paper. This won't fix applying to staff platform roles when your last three years were mostly on-call firefighting. It stops a strong pipeline file from dying on vague CI/CD language alone.
Below you'll see why Skills-only GitLab terms fail, which pipeline keywords recruiters search in Greenhouse, before/after pairs across platform and SRE roles, the exceptions, and what to change before you upload tonight.
When the portal asks for a letter, don't paste your Skills section into paragraph one. Generate a cover letter that cites the same .gitlab-ci.yml line you'll use in bullet one, then stop rewriting.
Quick Wins
- Name .gitlab-ci.yml, runners, and one deploy metric in bullet one.
- Move pipeline stages and CI/CD outcomes out of Skills into the job that shipped them.
- Match the posting's GitLab CI/CD spelling once at the top of Experience.
Why Skills-only GitLab terms fail in Greenhouse
Generic advice tells you to dump every tool you've touched into a Skills footer. US hiring teams and parsers in Greenhouse, Workday, and Lever weight dated Experience bullets higher than a comma-separated cloud. They search for proof you owned .gitlab-ci.yml files, not that you once completed a pipeline tutorial.
The contrast most DevOps files miss: recruiters don't pass because you forgot a buzzword. They pass when bullet one says built CI/CD pipelines and never names runners, stages, or a deploy outcome. The Skills row lists GitLab CI/CD next to Docker and Kubernetes with no job title above it. That reads like a keyword dump, not pipeline ownership.
A composite platform engineer whose top bullet still reads maintained CI/CD infrastructure for microservices loses to a file that opens with maintained .gitlab-ci.yml across thirty-eight repos on shared GitLab Runners, cutting average deploy time from 38 minutes to 11 minutes with parallel test stages. Same person. Different word order.
Platform reqs search runner tags, cache policies, and merge-train config. SRE reqs search incident hooks and deployment frequency. Product-adjacent backend reqs search test gates and artifact promotion. Pull phrases from the specific ad tonight, not a generic DevOps word cloud.
For how Experience text must parse before any keyword rewrite matters, read how to write resume experience ATS understands . If employer names detach from dates on upload, fix layout first. Then rewrite GitLab proof.
Edge case: you migrated from Jenkins to GitLab last year. Put Jenkins bullets under the legacy role with dates that match, and GitLab CI/CD bullets under the current role. Don't blend both stacks into one vague CI/CD line without a timeline.
Edge case: you used GitLab only for lint and unit tests while deploys ran elsewhere. Say you owned test stages and merge-request pipelines in .gitlab-ci.yml instead of claiming full CD when production lived in another tool.
GitLab CI resume keywords recruiters search in Greenhouse
Recruiters ctrl-f a short list before they read your summary. The table below shows where each term earns credit. Experience means a dated bullet under a job title. Skills means a repeat after proof exists above.
| Term | Experience bullet | Skills echo |
|---|---|---|
| .gitlab-ci.yml | Yes. Name file count or repo scope. | After it appears in a bullet. |
| GitLab Runner / runners | Yes. Name shared vs dedicated, executor type. | Optional repeat. |
| Pipeline / stages / jobs | Yes. Tie to deploy frequency or test gates. | Only if posting repeats them. |
| CI/CD | Yes, with a concrete outcome. | Fine as a single Skills token. |
| Artifacts / caching | Yes when you changed build time. | Skip if never in the req. |
| Docker / Kubernetes / Helm | Yes when deploy target matters. | Echo after bullet proof. |
Each pair below shows the same work with different emphasis. Replace bracketed fields with your real runner setup, stage count, and metrics. Keep bullet one under three lines in the PDF.
Platform engineer: duty vs .gitlab-ci.yml and runners
Before: Maintained GitLab CI/CD pipelines for microservices in a cloud environment.
After: Maintained .gitlab-ci.yml for forty-two Node.js services on shared GitLab Runners with Docker executors, cutting average pipeline duration from 34 minutes to 9 minutes via parallel test stages and dependency caching.
SRE: vague CI/CD vs deploy frequency proof
Before: Supported CI/CD tooling and deployment automation for production systems.
After: Owned GitLab CI/CD release pipelines with manual production gates and Slack deploy notifications, raising weekly deploy frequency from 6 to 22 releases across eight Kubernetes clusters without raising rollback rate.
DevOps generalist: skills dump vs pipeline stages
Before: GitLab, Jenkins, Docker, Kubernetes, Terraform listed in Skills. Experience says worked on build automation.
After: Standardized build, test, and deploy stages in .gitlab-ci.yml for fifteen Python services, adding merge-request pipelines that blocked merges when unit coverage dropped below 82%.
Backend engineer with platform overlap: maintenance vs artifacts
Before: Updated YAML files for the team's CI system and fixed broken builds.
After: Refactored .gitlab-ci.yml job templates to cache Maven artifacts between stages, shrinking nightly build time from 52 minutes to 19 minutes for six shared libraries consumed by twelve product teams.
I've screened stacks of DevOps files beside Greenhouse queues, and the GitLab CI resume keywords that survive the first ctrl-f are the ones where .gitlab-ci.yml, runners, and a deploy metric show up in bullet one without opening a second page.
Copy-paste GitLab CI bullet skeleton (edit every bracket)
[Verb] .gitlab-ci.yml for [repo/service count] [services/apps]
on [shared/dedicated] GitLab Runners with [Docker/Kubernetes/shell] executors,
[CI/CD outcome: cut pipeline time from X to Y / raised deploys from A to B per week],
using [stages: build, test, deploy] and [caching/artifacts/merge trains] where true.
Optional second line:
Integrated [Docker/Kubernetes/Helm/Terraform] deploy stages with
[manual gates / environment branches / review apps] for [team count] engineering squads.
Copy-paste the skeleton above, then swap brackets for your runner type, stage layout, and CI/CD outcome before you upload.
For broader CI/CD bullet patterns that pair well with GitLab terms, see CI/CD resume bullets that show real delivery impact . Lead with the GitLab surface the req names, then borrow outcome framing from that page if deploy frequency is the hook.
Exceptions and where these bullets go wrong
Not every GitLab term belongs in Experience. Certifications and clearances sometimes stay near the top. But most pipeline proof dies for predictable reasons even when the work is real.
When a keyword can stay in Skills only: you touched GitLab once on a six-month contract and your current role is pure AWS CodePipeline. List GitLab CI/CD in Skills with dates honest in Experience, but don't invent a GitLab bullet under today's title. Recruiters spot timeline gaps fast.
Runner type missing entirely. Bullets name pipelines but never say shared GitLab Runners, Kubernetes executors, or self-hosted shells. Postings for platform teams treat runner literacy as a filter. If you sized runner pools, say so with a count.
CI/CD with no deploy or test outcome. Recruiters do not credit CI/CD listed without frequency, duration, or gate policy. Move the number into the role that earned it. Skills can repeat the metric after it appears in Experience.
YAML mentioned without .gitlab-ci.yml. Generic maintained YAML configs reads like any CI tool. Name the GitLab file when that's what you edited. Parsers and recruiters both search the dotted filename.
Edge case: you shared pipeline ownership with another team. Name your slice: merge-request pipelines, release trains, or runner capacity. Shared platform work still needs a boundary object.
Edge case: the req wants GitHub Actions but your GitLab work was the migration source. Say you ported .gitlab-ci.yml stages to composite Actions workflows during a Q3 cutover instead of hiding GitLab entirely.
Do not stuff stages, jobs, includes, extends, and rules into one bullet unless the posting asks for advanced YAML literacy. Recruiters assume you know pipeline anatomy. They search for runners, outcomes, and the filename.
Two-column resume layouts scramble bullet order so pipeline proof lands under the wrong employer. For parser failures that kill keywords before a human reads them, read resume formatting errors that break ATS parsing .
Verify GitLab keywords against the req
A rewritten bullet dies if the parser still cannot read employer lines. Upload the same PDF you would send in Greenhouse and run a free ATS check on the posting. Confirm .gitlab-ci.yml, runners, and CI/CD show inside extracted Experience text, not only in Skills.
Fix bullet one before you apply. The checker should see pipeline terms on a dated line.
When you're choosing which platform reqs deserve an hour of rewriting tonight, score your job match on the posting first. A polished GitLab bullet cannot fix a skill gap on a staff SRE req if your last three years were mostly application support.
Rewrite bullet one tonight
Open your strongest platform or DevOps req. Highlight GitLab CI/CD, .gitlab-ci.yml, runners, and pipeline language in the posting. Rewrite bullet one under your current job so those objects appear in the first eight words with one CI/CD metric you can defend.
Copy the skeleton from the pairs section. Swap brackets for your executor type, stage layout, and deploy scope. Export a single-column PDF and confirm the line parsed under the right employer.
Job searching is already hard at mid level. You don't need a personality rewrite. You need GitLab CI resume keywords sitting on dated Experience lines where Greenhouse recruiters ctrl-f before they forward the file. When the wording still feels off, check your resume for free against the same posting before you hit submit.
Frequently asked questions
Put .gitlab-ci.yml, runners, pipelines, and CI/CD outcomes in dated Experience bullets first. A Skills row that lists GitLab CI/CD without a job title above it reads like a course you finished. One bullet that says you cut deploy time from 45 minutes to 12 minutes across fourteen microservices on shared GitLab Runners beats eight pipeline buzzwords with no employer context. Repeat tool names in Skills only after they appear under a role.
Recruiters ctrl-f GitLab CI/CD, .gitlab-ci.yml, GitLab Runner, pipeline, stages, jobs, artifacts, and CI/CD in Experience text before they open Skills. Kubernetes, Docker, Terraform, and Helm show up when the posting names them, but the GitLab-specific surface is what separates a platform req from a generic DevOps cloud. Match the posting's exact spelling once in bullet one, then use related terms naturally in bullet two.
Aim for four to six under your current platform or DevOps role and three to four on older jobs. Lead with the object the req searches: pipeline count, runner type, deploy frequency, or test coverage gates. Recruiters read the first two bullets under each employer in Greenhouse. If GitLab only appears in Skills, you look like you watched a tutorial instead of owning a pipeline.
Yes, when both are true, but don't split proof across both in one bullet. Put GitLab CI/CD bullets under the job where you maintained .gitlab-ci.yml and Jenkins bullets under the migration or legacy role. Parsers treat them as separate stacks. Stuffing both names into every line without dates makes neither stack credible.
Name internal consumer teams, repo count, or deploy windows instead of inventing public traffic numbers. Write maintained .gitlab-ci.yml for forty-two backend repos with scheduled nightly pipelines and manual production gates reads stronger than worked on CI/CD. Internal scope is still scale when you describe who depended on the pipeline.