Skip to content

chore: manage docker bloat on deployments#1981

Open
mentonin wants to merge 2 commits into
kernelci:mainfrom
profusion:georg/chore/prune-docker
Open

chore: manage docker bloat on deployments#1981
mentonin wants to merge 2 commits into
kernelci:mainfrom
profusion:georg/chore/prune-docker

Conversation

@mentonin

@mentonin mentonin commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

automatically prune old images and raise warnings for dangling volumes and exited containers on GitHub Actions workflow deployments.

Closes #1918

automatically prune old images and raise warnings for dangling
volumes and exited containers on GitHub Actions workflow deployments.

Closes kernelci#1918

Signed-off-by: Luiz Georg <luiz.georg@profusion.mobi>

@alanpeixinho alanpeixinho left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job

git checkout ${GITHUB_SHA} &&
docker compose -f docker-compose-next.yml pull &&
docker compose -f docker-compose-next.yml up -d
docker compose up --pull=always --remove-orphans --detach &&

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we changing the docker compose file here?
Shouldn't we be pointing to docker-compose-next.yml?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

cd dashboard-staging &&
git checkout ${GITHUB_SHA} &&
docker compose down &&
docker compose build --no-cache &&

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even with the policy of always pulling, isn´t it safer to build with no-cache here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

env:
SSH_HOSTKEY: ${{ secrets.STAGING_HOSTKEY }}

- name: Deploy production

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am just starting a discussion, do not take it as the best approach.
Wouldn´t it be better to leave the docker prune as a separate step here?
This way could even make it as an optional step, and if the cleanup fails the deploy process can still take place. Or would be better to fail imediatelly in such case?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, should we also remove docker builder cache? docker builder prune -f --filter "until=48h"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to avoid opening a second SSH connection, a separate step is indeed better. I moved them to another job altogether, so the status of the deployment job actually means whether deployment happened.

@mentonin
mentonin force-pushed the georg/chore/prune-docker branch 2 times, most recently from d88f321 to d8862dc Compare July 18, 2026 19:52
Signed-off-by: Luiz Georg <luiz.georg@profusion.mobi>
@mentonin
mentonin force-pushed the georg/chore/prune-docker branch from d8862dc to d8bf89b Compare July 18, 2026 20:01
@mentonin
mentonin requested a review from alanpeixinho July 18, 2026 20:01
@mentonin

Copy link
Copy Markdown
Contributor Author

@nuclearcat can you take a look at this? It would affect docker system-wide for staging, staging-db and production

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Prune old images from docker

2 participants