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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
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.
Related prompts
-
GitLab CI/CD artifacts:reports Wiring Prompt
Wire the structured artifacts:reports types (junit, codequality, sast, dotenv, coverage_report, accessibility) so MR widgets, the test tab, and downstream jobs all light up correctly.
-
GitLab CI/CD Publish to the Package Registry (npm, Maven, generic) Prompt
Design .gitlab-ci.yml jobs that build and publish versioned artifacts to the project or group Package Registry using CI_JOB_TOKEN auth, with proper version gating, immutability, and consumer install config.
-
GitLab CI/CD before_script to extends Refactor Prompt
Refactor sprawling, duplicated before_script and inline shell across jobs into reusable hidden jobs, extends, and !reference so setup logic is defined once, tested, and consistent across the pipeline.
-
CircleCI to GitLab CI/CD Migration Prompt
Translate a CircleCI config.yml into an idiomatic .gitlab-ci.yml, mapping orbs, workflows, executors, contexts, and caching to GitLab equivalents while flagging concepts that don't port cleanly.
More GitLab CI/CD prompts & error guides
Browse every GitLab CI/CD prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.