Pipelines: maintain pipelines · Topic 2 of 2
Artifact Retention and Migrating Classic Pipelines
AZ-400 retention: project retention settings, leases, release and feed retention, GitHub artifact retention, and migrating classic pipelines to YAML.
- 6 min
- Retention is a project level setting for runs: days for artifacts, runs and pull request runs, plus recent runs to keep.
- A run survives if it is retained indefinitely, under a lease, or used by a release.
- Cleanup runs once a day. Packages use feed retention, not run retention.
What it is
Pipelines produce data without limit: logs, artifacts, test results, packages. A retention strategy decides what is kept, for how long and where, balancing storage cost, compliance and traceability (being able to investigate an old release).
Migrating from classic to YAML moves pipelines that were built in the web designer into versioned files in the repository, which gives you code review, reuse and features the classic editor does not have.
How it works
Retention for pipeline runs in Azure DevOps
Retention is set in the project, under Project settings > Pipelines > Settings. Per pipeline retention rules are no longer supported.
| Setting | Meaning |
|---|---|
| Days to keep artifacts, symbols and attachments | How long run outputs are kept |
| Days to keep runs | How long the run record is kept |
| Days to keep pull request runs | A separate, usually shorter, period for pull request validation runs |
| Number of recent runs to keep for each pipeline | A minimum that is kept regardless of age. For Azure Repos it applies to the default branch and each protected branch (a branch with a branch policy) as well as the pipeline overall |
A run is deleted only when all are true: it is older than the configured days, it is not among the recent runs to keep, it is not marked to retain indefinitely, and it is not retained by a release. Cleanup is processed once a day. Deleting a run removes its logs, pipeline and build artifacts, symbols, binaries, test results, run metadata and the tags the Sources task created. The recent runs that are kept are counted from the succeeded and partially succeeded runs.
To keep a particular run longer:
- Retain it indefinitely from the run's menu, or add a retention lease (through the Lease API) for a set period. A pipeline step can add a lease, for example to keep production deployment runs longer than test ones.
- Copy the output out of Azure DevOps with the Copy files task to your own storage. Data published as build artifacts is still subject to cleanup.
YAML pipelines cannot set a different retention for each environment. Use leases or copying for production runs.
Classic release retention
Classic releases have their own rules per stage: the number of days to keep a release after it was last modified or deployed, a minimum number of releases to keep and whether to retain associated artifacts. There are organization level maximum and default policies, and a setting for when deleted releases are permanently destroyed. A release holds a retention lock on the runs it uses, which is why runs sometimes live longer than expected.
Test results
Test results have their own retention setting under Project settings > Test. Test results published in a release stage follow the test retention policy, not the release policy.
Dependencies and packages
Run retention does not govern packages. Azure Artifacts feeds have their own retention policies: a maximum number of versions per package and the number of days to keep recently downloaded packages. Packages promoted to a view are protected from deletion by the policy. Keep what builds still need and use views to mark versions that must stay.
Retention in GitHub
GitHub keeps workflow artifacts and logs for a default period of 90 days, which you can shorten or, within plan limits, set for the repository or organization. The retention-days input of actions/upload-artifact sets it for one artifact. Releases and packages are kept until you delete them.
Designing a retention strategy
| Data | Typical approach |
|---|---|
| Pull request runs | Short, such as days |
| Main branch runs | Weeks to months, plus a minimum of recent runs |
| Release builds shipped to customers | Keep indefinitely, or copy to immutable storage for compliance |
| Logs for audits | Export to Log Analytics or storage for the required period |
| Packages | Keep released versions, remove old pre-release versions |
Migrating classic pipelines to YAML
Why migrate: YAML lives in the repository, is reviewed and branched, supports templates, environments with checks and multi stage pipelines. Microsoft's investment is in YAML.
| Classic element | YAML equivalent |
|---|---|
| Build pipeline tasks | steps with the same tasks. In the classic editor, View YAML on a task shows the snippet |
| Release pipeline stages | stages and deployment jobs |
| Pre-deployment approvals | Approvals on an environment |
| Gates | Checks (Invoke Azure Function or REST API, Query Azure Monitor alerts) |
| Task groups | Templates |
| Variable groups and Key Vault links | Variable groups work in both |
| Deployment groups | Environments with virtual machine resources |
| Release triggers and artifacts | trigger, resources: pipelines, download |
A sensible approach:
- Inventory the pipelines and rank them by importance and use.
- Convert one at a time, starting with simple build pipelines. Reuse tasks and move shared logic to templates.
- Run both side by side: create the YAML pipeline with
trigger: none(or a different schedule) and queue it by hand to compare outputs against the classic one. - Cut over by enabling the YAML triggers and disabling the classic pipeline, keeping its history and retained builds viewable.
- Delete the classic pipeline later, once nobody needs its history.
To move from Azure Pipelines to GitHub Actions, the GitHub Actions Importer can audit, preview and convert pipelines.
A worked scenario
An auditor needs six years of evidence for production releases. The team keeps normal run retention short, but the deployment stage adds a retention lease for production runs and uploads the build output and test results to an immutable blob container with the Copy files task. Meanwhile they migrate the nightly classic build to YAML, run both for a week with the YAML pipeline queued by hand, then disable the classic one.
What to remember for the exam
- Retention is a project level setting for runs: days for artifacts, runs and pull request runs, plus recent runs to keep.
- A run survives if it is retained indefinitely, under a lease, or used by a release.
- Cleanup runs once a day. Packages use feed retention, not run retention.
- Use Copy files (not Publish build artifacts) to keep output beyond retention.
- Migrate to YAML side by side, then disable the classic pipeline. Task groups become templates, gates become checks.
Marking a run to retain indefinitely overrides all retention rules until you remove the flag. Review them from time to time.
How the exam asks about this
- "Keep production deployment runs longer than test runs in a YAML pipeline." A retention lease on those runs.
- "Keep build output for years for compliance." Copy it to your own storage.
- "Replace classic release approvals in YAML." Environment approvals and checks.
- "Retire a classic pipeline but keep its history." Disable it.
Common mistakes
Expecting run retention to delete packages. Feeds have separate rules.
Setting retention per pipeline in the new model. Only project settings apply.
Deleting the classic pipeline right away. You lose history and cannot compare results.
Forgetting releases lock runs. Old runs can stay because a release uses them.
Check yourself
At what level are Azure Pipelines run retention settings configured?
At the project level, in Project settings.
Which classic feature becomes a template in YAML?
Task groups.
How often does the retention cleanup process run?
Once per day.
Topic 2 of 2 in Pipelines: maintain pipelines
Test yourself on Pipelines: maintain pipelines
The full Microsoft AZ-400 question bank has 766 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.