-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"You are running out of disk space" Error. How can I fix this? #2840
Comments
Hello, @jessehui As a workaround:
|
@al-cheb Thank you for your reply. I would give it a try. I am just curious whether this limitation is added recently? Because we never encounter this error running the same workflow before. |
@al-cheb is there any way that you can provide more disk space to the customer? we do multistage docker build and 14 gb is too small for us, we are using 'ubuntu-latest' ado / azure pipelines .. not github actions
|
@jessehui , this limitation has always existed but previously, we have provided a bit more free space. Sometimes, image can have ~15-20 GB of free space and this volume can be changed without notice. We only guarantee that images contain at least 14 GB of free space. @arroyc , unfortunately, no. Only workarounds that Aleks has shared above |
@maxim-lobanov thanks for responding ... i just found following information in one of our builds ... its not even 14G ... its less than 10GB .. can you please confirm that? I'm assuming we are only using /dev/sda1
|
@al-cheb @maxim-lobanov Thank you for your help. We've managed to work this out. You may close this issue. |
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Signed-off-by: Brian Behlendorf <[email protected]>
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#11826
Recently we've been running out of free space in the ubuntu 20.04 environment resulting in test failures. This appears to be caused by a change in the default available free space and not because of any change in OpenZFS. Try and avoid this failure by applying a suggested workaround which removes some unnecessary files. actions/runner-images#2840 Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #11826
[ upstream commit e553bd2 ] We are having the below failure due to no disk space, it seems like we can remove pre-installed software and language runtimes, which are not use in Cilium, to reclaim more disk space. Alternative option is to bump the runner, but it might not be the best resource and cost utilization. Relates: https://github.com/cilium/cilium/actions/runs/10300396788 Relates: actions/runner-images#2840 (comment) Signed-off-by: Tam Mach <[email protected]> Signed-off-by: gray <[email protected]>
[ upstream commit e553bd2 ] We are having the below failure due to no disk space, it seems like we can remove pre-installed software and language runtimes, which are not use in Cilium, to reclaim more disk space. Alternative option is to bump the runner, but it might not be the best resource and cost utilization. Relates: https://github.com/cilium/cilium/actions/runs/10300396788 Relates: actions/runner-images#2840 (comment) Signed-off-by: Tam Mach <[email protected]> Signed-off-by: gray <[email protected]>
This is following the solution here: actions/runner-images#2840 (comment)
Lately we've seen frequent failures on macOS GitHub Action runs due to disk space issues. Poking with du(1) revealed that /Library/Developer/CoreSimulator/Caches/dyld was growing to be multiple gigbytes. Deleting unused stuff is a known workaround to space issues. actions/runner-images#2840 (comment)
Lately we've seen frequent failures on macOS GitHub Action runs due to disk space issues. Poking with du(1) revealed that /Library/Developer/CoreSimulator/Caches/dyld was growing to be multiple gigbytes. Deleting unused stuff is a known workaround to space issues. actions/runner-images#2840 (comment)
so it seems the suggestion above was not clearing up enough space for me. What I ended up doing was just deleting all the unused versions of Xcode from my Mac runner as one of the initial steps: - name: Delete Unused Xcode Versions
shell: bash
run: |
# when changing xcode version below, be sure to update this script!!!
echo "Deleting unused Xcode Versions..."
cd /Applications/
mv Xcode_15.4.app Ycode_15.4.app
sudo rm -rf Xcode*
mv Ycode_15.4.app Xcode_15.4.app I'm no bash expert, so I'm sure theres a more elegant way of doing this. Still have no idea why this randomly started on Friday for us though. Our builds were working fine. |
If you are using a Mac runner, one thing you might want to add to this list is all the versions of Xcode you are not using. We only needed Xcode 15.4, but these runners have half a dozen versions of Xcode installed. Thats a few GB of storage space for each. |
@BrentMifsud thanks for the breadcrumb here. You can remove all but the latest Xcode with: find /Applications/ -name "Xcode*" | sort -r | tail --lines=+2 | xargs rm -rf |
Thanks for this. Definitely much better than my solution |
great hint, thanks! i did implement it slightly different as you just have to remove the different folders and not each file individually:
In addition i coupled it with a matrix.xcode variable to initialization xcode in a specific version so basically what i initialize i want to keep and if i like i can run it against different versions of xcode.
|
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
actions/runner-images#2840 (comment) Signed-off-by: Martin Szuc <[email protected]>
## Motivation The build runs out of disk space which prevents adding new integration tests ## Modifications: * Free up some disk space by: * following the workaround described [in this ticket](actions/runner-images#2840 (comment)) * removing pre-pulled docker images * Add a new System property `camel.karaf.itest.keep.docker.images` to indicate whether the docker images should be removed after the test. Locally, you can leverage the Maven property `keep.docker.images.on.exit` to keep them or not. By default, the docker images are cleaned up to prevent the disk space leak * Extend the forked process exit timeout to ensure that pax-exam can stop properly
Some images (like slc9-gpu-builder) are too big for the free runner, so we need to remove some stuff before, mostly unused language packages Reference for the free disk space: actions/runner-images#2840 Builder error message: ``` ==> docker: At least 11799MB more space needed on the / filesystem. ```
Some images (like slc9-gpu-builder) are too big for the free runner, so we need to remove some stuff before, mostly unused language packages Reference for the free disk space: actions/runner-images#2840 Builder error message: ``` ==> docker: At least 11799MB more space needed on the / filesystem. ```
Some images (like slc9-gpu-builder) are too big for the free runner, so we need to remove some stuff before, mostly unused language packages Reference for the free disk space: actions/runner-images#2840 Builder error message: ``` ==> docker: At least 11799MB more space needed on the / filesystem. ```
Some images (like slc9-gpu-builder) are too big for the free runner, so we need to remove some stuff before, mostly unused language packages Reference for the free disk space: actions/runner-images#2840 Builder error message: ``` ==> docker: At least 11799MB more space needed on the / filesystem. ```
Description
The previous execution of this action never gives an error like this.
I think the reason is that the virtual environment is changed. But I am not sure. My question is whether there is a fix for this? I don't want to change the yaml file. Thank you. The action can be found here: https://github.com/occlum/occlum/actions/runs/619537350
Virtual environments affected
Image version
Image version where you are experiencing the issue.
Environment: ubuntu-18.04
Version: 20210219.1
The text was updated successfully, but these errors were encountered: