Skip to content

Conversation

@RyanHecht
Copy link
Contributor

Add disk space cleanup step to prevent runner disk exhaustion during Docker builds. Use dynamic repository owner/name for image tags to allow forks to publish to their own registries.

@RyanHecht
Copy link
Contributor Author

I wanted to make use of the PR Docker Build workflow to test another feature I was looking to add to Vikunja, but ran into two problems:

  1. The Actions runner ran out of disk space. I noticed this in some recent runs on the upstream repo as well. Copilot alerted my attention to https://github.com/jlumbroso/free-disk-space which aims to solve this problem.
  2. The docker meta step hardcodes the repo for which to use the container registry as go-vikunja/vikunja. This prevented me from publishing to my fork's container registry. I replaced this with variables that refer to the owner/repo that is running the Action

@RyanHecht
Copy link
Contributor Author

(Happy to split this up into two separate PR's if that's preferred!)

@kolaente
Copy link
Member

kolaente commented Dec 8, 2025

Well, since the build is still failing, I wonder if that's really a solution here.

@kolaente
Copy link
Member

kolaente commented Dec 8, 2025

Checking this again, the Docker build preview workflow only runs using the base pull request target, it does not take into account the changes that have been made to the workflow itself in a PR. That's why the changes from this PR don't run there.

I've incorporated the cleanup step in 7a05f20 - let's see if that works.

Pushing the changes to a fork does not need to work because it will always push the changes to the Vikunja main repo. It doesn't need to use the forked ghcr, it should just work. What issues did you encounter with that?

@RyanHecht
Copy link
Contributor Author

Well, since the build is still failing, I wonder if that's really a solution here.

Checking this again, the Docker build preview workflow only runs using the base pull request target, it does not take into account the changes that have been made to the workflow itself in a PR. That's why the changes from this PR don't run there.

Yes, that's correct -- I ran into this when testing it myself!

@RyanHecht
Copy link
Contributor Author

What issues did you encounter with that?

I received 403 errors when running this workflow from a base pull request target in my forked repo because my repo doesn't have permission to push to Vikunja's main repo.

Pushing the changes to a fork does not need to work because it will always push the changes to the Vikunja main repo.

While developing my feature, I wanted to be able to test it in a Docker image before submitting a PR upstream, making use of the existing workflow for publishing to GitHub Container Registry. I wanted the option of publishing to my fork's Container Registry instead of upstream's before I had proved that my feature worked as intended.

This functionality would also be useful for anyone wishing to maintain a customized fork of Vikunja

@kolaente
Copy link
Member

kolaente commented Dec 8, 2025

Ahh, now I understand your point. Thanks for clarifying. I'd say let's add this.

Since the cleanup changes are already integrated, can you rebase this PR so that it only contains the changes for the fork registries?

Use dynamic repository owner/name for image tags to allow forks to publish to their own registries.
@RyanHecht RyanHecht force-pushed the feat/pr-docker-workflow-improvements branch from ad0e735 to 9ba2fd0 Compare December 8, 2025 17:54
@RyanHecht
Copy link
Contributor Author

@kolaente Done!

Copy link
Member

@kolaente kolaente left a comment

Choose a reason for hiding this comment

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

Thanks!

@kolaente kolaente enabled auto-merge (squash) December 8, 2025 18:04
@kolaente kolaente merged commit 5784d8c into go-vikunja:main Dec 8, 2025
33 checks passed
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.

2 participants