ci: give the package artifact a retention period - #71
Merged
Merged
Conversation
kkdev92
changed the title
kkdev92
force-pushed
the
ci/artifact-retention-days
branch
from
September 21, 2026 05:59
0740198 to
098b374
Compare
The `nupkg` upload in `ci.yml` never set `retention-days`, so it fell back to this repository's default artifact retention of 90 days. Every run builds a fresh set of packages and no workflow reads an older one, so they were counting against the artifact storage allowance for three months to no purpose. The `coverage` upload earlier in the same workflow already uses 14 days. Reuse that value rather than introducing a second number. `release.yml` is left alone. It uploads and downloads an artifact that is also named `nupkg`, which is a separate artifact scoped to its own run: those steps pass only a name and a path, so each resolves within the run that is executing. How long CI keeps its own copy is a separate question from how a release is handled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kkdev92
force-pushed
the
ci/artifact-retention-days
branch
from
September 21, 2026 06:12
098b374 to
4696a59
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sets a retention period on the package artifact that CI uploads.
Why
The
nupkgupload inci.ymlnever setretention-days, so it fell back tothis repository's default artifact retention of 90 days. Those packages are
build output: every run produces a fresh set, and no workflow reads an older
one. They were occupying the artifact storage allowance for three months to no
purpose.
The
coverageupload earlier in the same workflow already usesretention-days: 14. This reuses that value rather than introducing a secondnumber.
What this does not change
release.ymlis untouched. The packages behind a release are published tonuget.org and attached to the GitHub release, so how long CI keeps its own copy
is a separate decision from how a release is handled.
Verification
retention-daysgoverns only how long an artifact survives after the run thatproduced it. A download within the same run is unaffected.
One thing is worth being explicit about, because the names collide:
release.ymlalso uploads an artifact callednupkg, and downloads it in threeplaces. Those are separate artifacts scoped to their own runs. Each of the three
download-artifactsteps passes onlynameandpath— norun-id, nogithub-token, norepository— so every one of them resolves within the runthat is executing. Nothing reads CI's copy from a later run, and the release
path does not depend on how long CI keeps its own.