Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
Keep approved sprite deliveries in a retention location chosen for releases. A CI artifact is useful build evidence, but its lifetime follows artifact retention settings. A link that worked during review may expire before a programmer or customer needs it.
Key Takeaways
- Separate temporary build evidence from retained delivery.
- Keep source revision and build instructions with the package.
- Verify downloads through the recipient's actual access level.
A successful build can leave no durable download
GitHub documents workflow artifacts as files produced by workflow runs. Do not present their URLs as permanent storage without checking the applicable artifact retention period. GitHub documents automatic deletion when that period expires.
A temporary contact sheet may be adequate for a short review. A release needs a clear answer to who retains the package, how long it stays available, and how a recipient identifies the approved version. Those are delivery decisions rather than generation settings.
Classify outputs before uploading
Separate disposable previews, review evidence, runtime assets, editable masters, and rebuild inputs. They may share storage, but need distinct access and retention decisions. A private reference board should not become public because a workflow uploads the entire workspace.
Use git ls-files to distinguish repository content from generated outputs. Record external inputs and exporter versions separately. A commit cannot reproduce manual cleanup performed only in a temporary build folder.
Choose an appropriate retained-release mechanism and verify its policy. Store a release record with the source revision, output identity, export preset, and retrieval location. Document who can replace or remove the package.
Example: the vanished NPC pack
A team approves a character ZIP linked from a workflow run. Later, the link becomes unavailable under the configured retention policy. The source remains in Git, but the final export preset and cleanup were never recorded.
Recovery requires more than restoring a convenient URL. Determine whether the approved files exist elsewhere, whether they can be rebuilt, and whether a rebuilt candidate matches the reviewed delivery. If identity cannot be established, mark the replacement as a new candidate and review it again.
For future handovers, publish the accepted package to the chosen retained location. A Git tag can label its source, but also retain the resolved commit. A label is not a substitute for the downloadable package.
Acceptance and maintenance
Test retrieval with the recipient's access level. Download and unpack the candidate into a clean location, then inspect the required textures, timing data, and example scene. Record what happens when a package is superseded or intentionally removed.
Assign a retention owner who can notice policy changes. Keep a recoverable copy when your delivery promise requires one. Do not imply that any hosted service guarantees indefinite storage simply because its current download works.
This is a proposed retention and recovery procedure. No expired artifact, rebuild, or long-term availability was tested here. When the approved output cannot be recovered, report that uncertainty rather than claiming a regenerated ZIP is identical.
Related workflow
See game asset pack preview zip inventory check for the adjacent failure. Keep the animation handoff checklist with the package and record visual decisions in the art reference board.
Prepared by the FrameSprite Workflow Team. Editorial method · Corrections. Primary documentation checked 2026-10-20.
Top comments (0)