v7 uploads workflow files and returns three useful identifiers
Upload-artifact v7 takes a file, directory, wildcard, or list of paths and stores the result with the workflow run. A successful step returns an artifact ID, a signed-in download URL, and a SHA-256 digest. Most teams will use the default zipped form. The newer archive: false option sends one file directly, which helps when an archive would only wrap an archive, although that mode ignores the configured artifact name and uses the filename.
The action has more policy controls than its short YAML example suggests. Retention accepts 1 through 90 days unless repository settings allow otherwise, compression ranges from 0 through 9, and one job can create up to 500 artifacts. Our 54-file checkout was only about 1,653 source lines, yet installation pulled 699 packages and occupied 316 MB. The workflow surface is small; the development dependency tree is much larger.
What happened when we ran it
Our sandbox installed upload-artifact in 29 seconds, adding 699 npm packages and consuming 316 MB on disk. The TypeScript build passed in 14 seconds. Jest then finished in 17 seconds with 31 passed and 0 failed out of 31. We ran commit 043fb46 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22 as the base image, and no secrets.
Npm audit found 14 known vulnerabilities in that installed tree: 3 critical, 9 high, 1 moderate, and 1 low. The measurement block does not identify which runtime paths reach those packages, so we cannot turn the severity totals into an exploit claim. The repository also had 7 CI workflow files, a tests directory, and no Dockerfile. Our run proves that its provided build and test commands worked in this container; it does not measure upload speed or GitHub service reliability.
GitHub-hosted Actions gets v7, while GHES remains on v3.2.2
The current README draws a hard platform line. Upload-artifact v4 and later do not support GitHub Enterprise Server. GHES users are directed to v3.2.2 for Node 24 or v3.2.2-node20 for Node 20, while the examples for GitHub-hosted Actions use v7. This is a purchasing constraint, not a small setup wrinkle: a company running GHES cannot copy the current examples and expect the current action generation to work.
On GitHub-hosted Actions, the basic configuration is pleasantly short: pin the action, provide path, and optionally set a name. The same 29-second lab install that pulled 699 packages matters to contributors, but normal workflow consumers run GitHub's bundled action rather than installing the repository themselves. There is no Dockerfile to operate and no separate storage server to provision. The artifact still lives under GitHub's workflow run, so availability follows the run, repository, and retention settings.
Immutable artifact names prevent merging across matrix jobs
Since v4, an artifact cannot be changed after creation. Two jobs using the same name do not merge their files, and the later upload fails. Matrix workflows need a distinct suffix such as the operating system and matrix version. The overwrite input deletes an existing artifact before creating another one, which produces a new artifact ID. Any downstream step that stored the previous ID must be designed for that replacement.
File fidelity needs its own decision. With zipped upload, directories are restored as mode 755 and files as 644, so executable bits are not preserved. The README recommends creating a tar file and sending that single file with archive: false when modes and case sensitivity matter. That workaround should be tested in the actual consumer job. Our 31 passing tests confirm the repository suite at commit 043fb46, not every permission-sensitive archive produced on every runner.
Hidden files stay excluded unless the workflow opts in
Hidden files and files inside dot-directories are skipped by default. Setting include-hidden-files: true includes them, and path exclusions can then remove secrets such as an environment file. Open issue 614 argues that an explicitly named dotfile should upload without enabling all hidden files; it was updated on August 27, 2026. Until that behavior changes, a workflow should inspect the resolved file set instead of assuming an explicit dotfile path overrides the safety default.
The repository is maintained differently from a typical community project. GitHub recorded 262 combined issues and pull requests, a last push on April 14, 2026, and release v7.0.1 on April 10. Issue activity continued into September 2026, but the README says outside contributions are currently paused. Bug reports remain welcome; high-priority problems are routed to GitHub Community Discussions or support, while security updates and major breakage remain in scope. The 7 CI workflows show active project checks, not an open contribution promise.
Signed-in, expiring downloads make this a CI handoff tool
The artifact URL only works for signed-in users, and it remains valid only while the artifact, workflow run, and repository exist and the retention window has not ended. That is a sound fit for test reports, compiled binaries passed to another job, and logs attached to an internal run. It is a poor match for a public download page. A GitHub Release action puts distributable files in a place intended for users rather than tying them to a workflow's 1-to-90-day artifact policy.
The final choice is unusually clear. Our run built in 14 seconds and passed all 31 tests, so the checked-out action code cleared its basic engineering checks. The 14 audit advisories deserve review before local development or redistribution, and the platform caveats should be designed into the workflow from day one. Use upload-artifact v7 for temporary output inside GitHub-hosted Actions. Use Cache for reusable inputs, Upload Pages Artifact for Pages, or a release action for durable public files.