CI/CD improvements often arrive as small toggles that don’t look headline-worthy—until you run a large platform and realize those toggles remove hundreds of tiny cuts. GitHub Actions’ new ability to upload and download non-zipped artifacts is one of those changes. If you’ve ever uploaded a single HTML report, a SARIF file, or a coverage summary just to force your users to download a zip, unzip it, and then open one file, you know the feeling.
In late February 2026, GitHub added support for unarchived artifacts through the official actions. The feature is opt-in, but it’s a meaningful quality-of-life upgrade for teams standardizing pipelines and trying to reduce workflow friction.
What changed (and what didn’t)
Historically, actions/upload-artifact would zip your artifact payload automatically. Downloads—whether through actions/download-artifact or via the GitHub UI—would deliver a zip file. That behavior was simple, but it created three recurring problems:
- Single-file artifacts: a zip wrapper is pure friction.
- Browser viewing: modern browsers can display HTML, markdown, images, and text directly—but not if everything is zipped.
- Double-zip: teams often upload a compressed file (to preserve permissions, reduce size, or keep a bundle together) and then GitHub zips it again, turning “zip” into “zip-inside-zip.”
The new model is straightforward: with actions/upload-artifact@v7 you can set archive: false to upload without the extra zip step. And you can download unzipped using actions/download-artifact@v8.
Why platform engineering teams should care
If you operate “CI as a platform,” artifacts are part of your developer experience. Artifacts are how teams debug failing builds, review test evidence, and audit release pipelines. Anything that lowers the cost of access—especially for browser-based inspection—reduces context switching and speeds up incident resolution.
In practice, non-zipped artifacts enable a couple of useful patterns:
- Human-friendly reports: HTML reports can be viewed immediately after download without an unzip step.
- Mobile workflows: on-call engineers on phones can inspect simple artifacts without wrestling with archive management.
- Security evidence: single-file evidence artifacts (SBOM summaries, attestations, scans) become easier to fetch and verify quickly.
How to adopt it safely
For most organizations, the adoption plan should be conservative: update a small number of workflows first, validate the developer experience, then roll out broadly via reusable workflow templates.
1) Update the upload and download actions together
If your workflows upload with v7 and download with an older action, you may still see zipped behavior. Treat this as a paired upgrade: upload-artifact@v7 + download-artifact@v8.
2) Use non-zipped mode for truly single-file outputs
Unzipped artifacts shine when the artifact is one file or a small set of files intended to be consumed individually. For multi-file directory structures (e.g., full test report trees), zip still provides convenience and fewer API calls.
3) Watch artifact retention and size behavior
The change is primarily about packaging, not about retention policy. But because packaging affects compression ratios, it can affect storage and transfer size. Validate that your heaviest workflows don’t regress in runtime or storage footprint.
4) Standardize through internal templates
If you maintain centralized workflow templates, this feature is a clean “DX win” you can roll out across the org without requiring every repo to reinvent the pattern.
Zooming out: this is CI becoming more product-like
CI platforms are increasingly treated like products: they have user experiences, affordances, and friction points. GitHub’s artifact change is a signal that the platform is smoothing the edges for day-to-day developer usage, not just adding new enterprise knobs.
For teams building internal developer platforms, the lesson is to sweat the small stuff. If your artifact handling requires extra manual steps, that’s a platform bug—just like a slow build or a flaky test.
Leave a Reply