<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=17260) </details> <!--IssueSummary end--> We should enable easier control over artifact expiration for tagged artifacts. We can do this in a couple of ways, some suggestions have been: * At the server level, adding an extra option to exempt tagged artifacts from expiration entirely or offering a separate duration option. * At the project level, through an easier method in `gitlab-ci.yml` without requiring an independent job. * At the project level, in a project level setting. ## Server level setting At the server level seems pretty blunt, and it's unclear how that setting would interplay with a duration specified in `gitlab-ci.yml`. Would the server or CI setting take precedence? If the CI setting should take precedence, which it should, we should make it easier to solve this problem without needing a specific job for tagged jobs since it would be needed anyway. ## Improvement to `gitlab-ci.yml` Which brings us to a project level setting in `gitlab-ci.yml`. As noted this can be done today by creating a specific job for tags, but this means that commands for the pipeline would need to be maintained in another specific job. This seems less than ideal. ## Project level setting Another option is to create a setting which would override anything in `gitlab-ci.yml`, but leave this at the project setting so it could be independently managed outside of a complete server global setting. My personal preference is come up with a method of specifying this more cleanly in `gitlab-ci.yml`. Having overrides for specific cases outside of that file is confusing, and prone to not being very discoverable.