Versions
How to update an artifact without changing its share URL, and how version history behaves across runs.
In short
Publishing a new version against an existing artifact id replaces the content behind the same share URL. This is what makes a recurring report workable: reviewers keep one link and always see the current run.
Updating in place
Post the new HTML to the artifact's versions endpoint with the artifact id. The share URL does not change, and the next person to load it sees the new content.
Give each version a label. A date, a commit hash, or a run number is enough to make the history readable later.
Keeping the id
This is the step people miss. If your job does not store the artifact id from the first publish, every run creates a new artifact and a new URL, which recreates the problem you were trying to solve.
Store the id wherever the job already keeps state: a config file, a CI variable, a row in your own database.
Limits
Version history is capped per artifact. Reaching the cap returns an explicit error rather than silently discarding older versions.
- Versions per artifact on Builder
- 25
- Versions per artifact on Pro
- 200
- Share URL changes on update
- No