GitLab CI/CD artifacts:expose_as Merge Request Artifact Linking Prompt
Surface build outputs — coverage HTML, Lighthouse reports, screenshots, bundle stats — as one-click links directly on the merge request using artifacts:expose_as, so reviewers stop downloading zip files to see results.
- Target user
- Engineers who want review-time visibility of pipeline outputs
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a GitLab CI workflow engineer who makes pipeline outputs reviewable without leaving the merge request, using artifacts:expose_as correctly and within its constraints. I will provide: - The job(s) producing reviewable outputs and the paths they write (e.g., `coverage/index.html`, `lighthouse/report.html`, `screenshots/`) - Where reviewers currently have to go to see them (download artifact, browse CI, external dashboard) Your job: 1. **expose_as block** — write `artifacts:expose_as:` paired with the right `artifacts:paths:` for each output so a labeled link appears in the MR's "View exposed artifact" area. Show the YAML per job. 2. **The single-file-vs-directory rule (CRITICAL)** — explain expose_as constraints: paths must not use wildcards in the exposed path, a single exposed file opens directly while a directory exposes a browsable list, and there's a cap on the number of exposed artifacts per MR. Make my paths comply. 3. **Pretty links** — choose human-readable `expose_as:` labels (e.g., "Coverage report", "Lighthouse", "Visual diffs") instead of raw paths. 4. **Pair with reports** — note where `artifacts:reports:` (coverage, codequality) gives inline MR widgets and where `expose_as` is the better fit (rich HTML you want to click into). Recommend which to use for each of my outputs. 5. **Expiry & cost** — set `artifacts:expire_in:` so these don't accumulate, and warn that exposed artifacts vanish when the artifact expires, breaking the MR link. 6. **Verify** — tell me exactly where on the MR the link appears and how to confirm it resolves to the right file. Output: (a) per-job `artifacts:` blocks with `expose_as`, `paths`, and `expire_in`, (b) the constraint fixes for any non-compliant path, (c) the reports-vs-expose_as recommendation per output, (d) where to find the link on the MR. Bias toward: clickable HTML reports over downloadable zips, readable labels, and expiry that balances reviewer access with storage cost.
Why this prompt works
Reviewers vote with their clicks. If seeing the coverage report or the visual-diff screenshots for a merge request means downloading a zip, unpacking it, and opening files locally, most people just won’t — and the pipeline’s most useful outputs go unread. artifacts:expose_as fixes this by putting a labeled link right on the MR page, but it has constraints that aren’t obvious from the docs: wildcards in the exposed path silently disable it, single files behave differently from directories, and there’s a per-MR cap. This prompt encodes those constraints so the model produces config that actually renders a link instead of YAML that looks right and does nothing.
The genuinely useful part is the division of labor between expose_as and artifacts:reports:. They overlap in people’s minds but solve different problems: reports: drives the inline MR widgets (coverage percentage, code-quality deltas, test summaries) while expose_as is for rich HTML you want to click into — a full Lighthouse report, a coverage browser, a screenshot gallery. Asking the model to recommend which mechanism fits each of your outputs means you get the inline number and the deep link where each makes sense, rather than forcing everything through one channel.
Expiry is the quiet failure mode this prompt heads off. Exposed links are backed by the underlying artifact, so when expire_in lapses the MR link dies — and there’s nothing more frustrating than clicking a “Coverage report” link on a week-old MR and getting a 404. By making the model set expiry deliberately against the review window and flag the breakage, you avoid shipping a feature that works in the demo and rots a week later.