Attempt and await all Docker cleanup without failing Dependabot jobs - #1753
Merged
Merged
Conversation
jeffwidman
changed the title
jeffwidman
commented
Aug 10, 2026
The test mocked Dockerode end to end, so it only verified that cleanup awaited a promise supplied by the mock. It did not exercise Dockerode's promise implementation or prove that an image was removed. The Docker-backed integration test already verifies cleanup through the real client and daemon, including the resulting image state immediately after cleanup resolves. Keep that as the authoritative coverage instead.
Attempt network pruning, container pruning, and each updater or proxy image cleanup independently so one Docker error cannot suppress the remaining housekeeping work. Await every repository cleanup and report operation-level failures with contextual error annotations without calling core.setFailed. Keep individual image-removal failures informational because images may still be referenced or encounter expected Docker races. Add deterministic orchestration coverage, prevent duplicate import-time cleanup in the integration test, and rebuild the checked-in cleanup bundle.
jeffwidman
changed the title
# Conflicts: # dist/cleanup/index.js # dist/cleanup/index.js.map
ruben-pachecocaldera
approved these changes
Aug 18, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The cleanup post-action could return before Docker image cleanup finished, leaving stale updater and proxy images behind. This is most impactful on persistent self-hosted and GHES runners, where Docker state survives across jobs and unused images can accumulate over time.
Awaiting cleanup fixes that problem, but it also means Docker errors can propagate. One failed prune or image lookup should not prevent the remaining housekeeping, and a cleanup problem should not turn an otherwise successful Dependabot update into a failed job.
Behavior and impact
This PR makes cleanup best effort, fully awaited, and non-fatal. Network pruning, container pruning, and each updater or proxy image cleanup are attempted independently, so one failure cannot suppress the rest. Operation-level failures remain visible through error annotations, but they do not fail the Dependabot job.
As a result, persistent runners get more reliable cleanup without making update jobs less reliable. Individual image-removal failures remain informational because images may still be referenced or affected by normal Docker races.
Covered by focused unit and Docker integration tests; the checked-in action bundle has been rebuilt.