For engineering teams
Turn CI output, code review reports, and release packets into links that live in the pull request instead of build artifacts nobody downloads.
The situation
Your pipeline already produces HTML: coverage reports, bundle analyses, agent-written review summaries, release notes. Today they are build artifacts behind three clicks, or they are pasted into a comment as a wall of text. Reviewers do not open them, so the work that produced them is wasted.
What you are publishing
- CI report output
- Coverage, bundle size, performance budgets, and test summaries rendered as a document instead of a log file.
- Agent code review packets
- Findings, annotated snippets, and a remediation checklist produced by an automated review pass.
- Release sign-off packets
- Change summary, risk notes, and verification evidence gathered into one link for the person approving the release.
What matters most here
The link goes in the pull request
A URL in the job summary or a PR comment gets opened. A downloadable artifact does not.
Short expiry for ephemeral work
A report tied to a branch can expire in days. Nothing accumulates, and nobody has to write a cleanup job.
Agents can publish directly
A review agent connected over MCP publishes its own output and returns the URL as part of its response.
Sandboxed rendering
Reports assembled from repository content and model output render in a sandbox rather than executing with your session's privileges.
How the workflow runs
- 01Produce the report as one self-contained HTML file in the build.
- 02Publish it with a short expiry, tagged with the commit or branch in the title.
- 03Write the returned URL into the job summary or a pull request comment.
- 04For release packets, publish each part into a shared project and share the project link.
- 05Let short-lived reports expire on their own.
The questions this team asks first
Why not just use the CI system's artifact storage?
Use it if reviewers actually open it. Artifact storage is good at retention and bad at being clicked. The case for a link is purely that people read it; if your team already downloads build artifacts, keep what works.
Does the API key belong in CI?
Store it as a secret and scope publishing to the jobs that need it. Treat it like any other credential in your pipeline.
Can a report contain source code?
Technically yes, but think about it first. Unlisted links are openable by anyone holding the URL, so a report quoting proprietary code needs private visibility on Pro, or redaction before publishing.