Refactor artifact cleanup #484
Conversation
…rtifact job itself
…days to upload-artifacts job
|
EDIT: I learned that native providers are no longer managed via this repository. This will not fix any native provider CI. |
|
@iwahbe based on feedback from @thomas11 I removed the retention days from any workflows triggered by tags. We will keep release and prerelease artifacts for the default 90 days. |
There was a problem hiding this comment.
@iwahbe based on feedback from @thomas11 I removed the retention days from any workflows triggered by tags. We will keep release and prerelease artifacts for the default 90 days.
That doesn't sound right to me. We are able to access release artifacts that are older than 90 days. This is the pulumi-aws v5.18.0, released mid-october of 2022. All the released artifacts are accessible.
The artifacts as stored as part of the release action are inaccessible, but that doesn't matter. We don't expect users to consume artifacts from of the release action, just the actual release.
I think a 30 day retention period is fine. There isn't a clear reason to special case these workflow artifacts compared to other workflow artifacts.
This pull request removes the
artifact-cleanup.ymlWorkflow from all managed providers.Instead, we will use the
retention-daysfeature of theupload-artifactAction to have artifacts expire after 30 days.Previously, we ran the artifact cleanup Workflow on a cron that would remove all artifacts older than 30 days.
With this change, we are setting artifacts to expire after 30 days instead of the default 90 days that
upload-artifactprovides.This is a very likely fix for pulumi/pulumi-azure-native#2558 and pulumi/pulumi-kubernetes#2499, et al, since the Action we used in
artifact-cleanup.ymlcaused a secondary rate limit error.Related: pulumi/pulumi-aws#2649.
h/t to @aq17 for finding this neat feature of
upload-artifact❤️