Skip to content
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

Significantly less available disk space in macos-14-arm64 #10511

Closed
2 of 13 tasks
ehuss opened this issue Aug 30, 2024 · 26 comments
Closed
2 of 13 tasks

Significantly less available disk space in macos-14-arm64 #10511

ehuss opened this issue Aug 30, 2024 · 26 comments

Comments

@ehuss
Copy link

ehuss commented Aug 30, 2024

Description

The 20240827.4 release of the macos-14-arm64 image seems to have significantly less available disk space than the previous release (20240818.4). I wanted to check if this was intended or expected. This is unfortunately causing our builds to fail.

20240827.4 initial space:

Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   295Gi   9.6Gi    18Gi    35%    404k  190M    0%   /
devfs            195Ki   195Ki     0Bi   100%     674     0  100%   /dev
/dev/disk3s6     295Gi    20Ki    18Gi     1%       0  190M    0%   /System/Volumes/VM
/dev/disk3s2     295Gi   4.9Gi    18Gi    22%     153  190M    0%   /System/Volumes/Preboot
/dev/disk3s4     295Gi   288Ki    18Gi     1%      23  190M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi    20Ki   495Mi     1%       0  5.1M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi    96Ki   495Mi     1%      20  5.1M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   196Ki   495Mi     1%      17  5.1M    0%   /System/Volumes/Hardware
/dev/disk3s5     295Gi   261Gi    18Gi    94%    2.2M  190M    1%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home

compared to 20240818.4 initial space:

Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1s1   295Gi   9.6Gi    57Gi    15%    404k  593M    0%   /
devfs            195Ki   195Ki     0Bi   100%     674     0  100%   /dev
/dev/disk3s6     295Gi    20Ki    57Gi     1%       0  593M    0%   /System/Volumes/VM
/dev/disk3s2     295Gi   4.9Gi    57Gi     9%     153  593M    0%   /System/Volumes/Preboot
/dev/disk3s4     295Gi   272Ki    57Gi     1%      14  593M    0%   /System/Volumes/Update
/dev/disk1s2     500Mi    20Ki   495Mi     1%       0  5.1M    0%   /System/Volumes/xarts
/dev/disk1s1     500Mi    96Ki   495Mi     1%      20  5.1M    0%   /System/Volumes/iSCPreboot
/dev/disk1s3     500Mi   196Ki   495Mi     1%      17  5.1M    0%   /System/Volumes/Hardware
/dev/disk3s5     295Gi   222Gi    57Gi    80%    2.1M  593M    0%   /System/Volumes/Data
map auto_home      0Bi     0Bi     0Bi   100%       0     0     -   /System/Volumes/Data/home

Platforms affected

  • Azure DevOps
  • GitHub Actions - Standard Runners
  • GitHub Actions - Larger Runners

Runner images affected

  • Ubuntu 20.04
  • Ubuntu 22.04
  • Ubuntu 24.04
  • macOS 12
  • macOS 13
  • macOS 13 Arm64
  • macOS 14
  • macOS 14 Arm64
  • Windows Server 2019
  • Windows Server 2022

Image version and build link

20240827.4

https://github.com/rust-lang-ci/rust/actions/runs/10612800738/job/29415273318

Is it regression?

Yes, 20240818.4 works. https://github.com/rust-lang-ci/rust/actions/runs/10622377375/job/29446525166

Expected behavior

Would like to have more than 18GiB free when starting.

Actual behavior

Only 18GiB free when starting.

Repro steps

  1. Run a job on macos-14-arm64 that uses the new image.
@susmitamane
Copy link
Contributor

Hi @ehuss

We are looking into it. Will keep you posted.

@erik-bershel
Copy link
Contributor

Hey @ehuss!

Please, see the description of GitHub hosted runners bellow:

Thank you for bringing this fact to our attention. Most likely, it is related to the fact that a new Xcode with all SDKs and simulators was added to the assembly, but this still fits into the stated service agreement and is not a regression. Please, see the description of GitHub hosted runners bellow:

Just in case, we will of course check what exactly led to such a sharp decrease in space and will try to do something about it, but unfortunately we cannot make any promises. MacOS images are the most voluminous and it is quite difficult to remove something from there without negatively affecting the experience of other users. If your builds require additional space, CPU or RAM, then I recommend paying attention to Larger Runners:

@nth10sd
Copy link

nth10sd commented Aug 30, 2024

Is there any equivalent cleanup command as per #10386 but for macOS runners instead?

@workingjubilee
Copy link

workingjubilee commented Aug 30, 2024

I appreciate you looking into this, but regarding the recommendation to use larger runners for macOS, I am curious: which one is the one with more than 14GiB storage (as promised by service contract), exactly?

Runner Size Architecture Processor (CPU) Memory (RAM) Storage (SSD) Workflow label
Large Intel 12 30 GB 14 GB macos-latest-large, macos-12-large, macos-13-large [latest], macos-14-large[Beta]
XLarge arm64 (M1) 6 (+ 8 GPU hardware acceleration) 14 GB 14 GB macos-latest-xlarge, macos-13-xlarge [latest], macos-14-xlarge[Beta]

@erik-bershel
Copy link
Contributor

Hey @nth10sd!

We'll definitely propose something like that to you later. It's a good temporary solution I think.

@erik-bershel
Copy link
Contributor

Hey @workingjubilee!

Nice input. I checked up with the corresponding team and it seams that you are right - there is no option to extend disk space for macOS as it might be done for the Ubuntu/Windows images.

Given the above and all the information in general, the best solution would be to try to increase the free space on our side - we will try to work on this. As an interim solution, we will develop a couple of small scripts that can be implemented in your CI in order to free up space on the runner by removing components that are not needed at the moment.

cc: @ehuss

@the8472
Copy link

the8472 commented Aug 30, 2024

APFS seems to support reflinks/file clones. Has deduplication been applied to the runner images? If not then that might save some space.

@igorGevaerd
Copy link

We are suffering from the same issue too

bors added a commit to rust-lang-ci/rust that referenced this issue Aug 31, 2024
…orkingjubilee

Try to reduce space usage in dist CI

We have had recurrent CI problems as a result of GitHub adding a new version of Xcode to its runners[^0], which has consumed ~40GB of space which served as padding. Try to reduce the number of Xcodes on our systems, because we only use Xcode 14 in actual practice. Also, try to move files instead of pointlessly copy them when we're at the end of the job.

I could not resist addressing a few shellcheck lints while I was at it.

[^0]: actions/runner-images#10511
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 31, 2024
…orkingjubilee

Try to reduce space usage in dist CI

We have had recurrent CI problems as a result of GitHub adding a new version of Xcode to its runners[^0], which has consumed ~40GB of space which served as padding. Try to reduce the number of Xcodes on our systems, because we only use Xcode 14 in actual practice. Also, try to move files instead of pointlessly copy them when we're at the end of the job.

I could not resist addressing a few shellcheck lints while I was at it.

[^0]: actions/runner-images#10511
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Sep 1, 2024
…ilee

Try to reduce space usage in dist CI

We have had recurrent CI problems as a result of GitHub adding a new version of Xcode to its runners[^0], which has consumed ~40GB of space which served as padding. Try to reduce the number of Xcodes on our systems, because we only use Xcode 14 in actual practice. Also, try to move files instead of pointlessly copy them when we're at the end of the job.

I could not resist addressing a few shellcheck lints while I was at it.

[^0]: actions/runner-images#10511
@StephenHodgson
Copy link

+1 for tracking. Also running into this.

@gabe4coding
Copy link

Suffering of this as well +1

@fabioferrero
Copy link

+1 also on our side

@the8472
Copy link

the8472 commented Sep 2, 2024

You can 👍 the issue instead of adding new comments.

@StephenHodgson
Copy link

👍

@quark17
Copy link

quark17 commented Sep 3, 2024

We encountered this as a sudden failure of Homebrew to install the mactex-no-gui package, with only the cryptic message: installer: The install failed..

Searching the issues in this repo didn't turn up anything -- hopefully, mentioning Homebrew in this comment will help someone searching in the future. I was eventually able to discover where the Homebrew installer logs are recorded and saw messages that the package needed 8.89 GB but only 7.99 GB was available. The install works on macos-12 and macos-13 runners, which still have enough space. But this alerted to me how much space the mactex-no-gui bundle needed. We are able to workaround the decrease in space by installing the Homebrew texlive target instead, which is smaller.

@jamescrosswell
Copy link

I ran into this issue on our macos runner. After doing a bit of sleuthing with df and du to work out what was consuming so much disk space I discovered all of these in the Applications folder:

44G	/Applications
 11G	/Applications/Xcode_14.3.1.app
 4.9G	/Applications/Xcode_15.4.app
 4.9G	/Applications/Xcode_15.3.app
 4.8G	/Applications/Xcode_15.2.app
 4.5G	/Applications/Xcode_15.1.app
 4.5G	/Applications/Xcode_15.0.1.app
 4.3G	/Applications/Xcode_16_beta_6.app
 4.3G	/Applications/Xcode_16.1_beta.app

We do use Xcode as part of our build, but we only need one of those versions of Xcode (not all of them). So the solution in our case was to delete a bunch of the old ones:

      # We only use Xcode 15.4
      - name: Remove unused applications
        run: |
          df -hI /dev/disk3s1s1
          sudo rm -rf /Applications/Xcode_14.3.1.app
          sudo rm -rf /Applications/Xcode_15.0.1.app
          sudo rm -rf /Applications/Xcode_15.1.app
          sudo rm -rf /Applications/Xcode_15.2.app
          sudo rm -rf /Applications/Xcode_15.3.app
          df -hI /dev/disk3s1s1

... which frees up about 30GB of space.

@Vyazovoy
Copy link

Vyazovoy commented Sep 4, 2024

Here is a step that will delete all beta versions of Xcode unless you explicitly selected one:

- name: Delete unused Beta Xcode installations
   run: |
     echo "Available Xcode installations:"
     xcodes installed
     selected_path="$(xcode-select -p)"; selected_path="${selected_path%/Contents/Developer}"
     find /Applications \
       -depth 1 \
       -name "Xcode*beta*.app" \
       -not -path "${selected_path}" \
       -exec rm -rf {} +

@JoeSzymanskiFAN
Copy link

In addition to the above suggestions to delete unused versions of Xcode, we were able to add a significant amount of space by deleting unused simulators and clearing the simulator cache:

echo "Deleting all iOS simulators"
xcrun simctl delete all

# Do the following only if you need a simulator for things like unit tests
echo "Creating an iOS simulator to run unit tests"
xcrun simctl create "Unit-Test-Device" "iPhone 15 Pro Max" "iOS17.5"

# This folder starts at 42 GB and sometimes increases to as high as 61 GB.
# After deleting it and running a build, the final size is only 12 GB, so this is
# a good target for disk space savings.
echo "Deleting iOS Simulator caches"
sudo rm -rf ~/Library/Developer/CoreSimulator/Caches/*

Ashoat added a commit to CommE2E/comm that referenced this issue Sep 5, 2024
Summary: This diff does two things:

1. Brings back D9464, which was previously removed in D11202
2. Implements the changes suggested in [this GitHub comment](actions/runner-images#10511 (comment)) to delete iOS simulators and associated caches

Test Plan: I landed the changes to `android_ci.yml` directly on master and confirmed that the GitHub Actions run succeeded: https://github.com/CommE2E/comm/actions/runs/10722767078/job/29734470192

Reviewers: varun, will

Subscribers:
Ashoat added a commit to CommE2E/comm that referenced this issue Sep 5, 2024
Summary:
This diff does two things:

1. Brings back D9464, which was previously removed in D11202
2. Implements the changes suggested in [this GitHub comment](actions/runner-images#10511 (comment)) to delete iOS simulators and associated caches

Test Plan: I landed the changes to `android_ci.yml` directly on master and confirmed that the GitHub Actions run succeeded: https://github.com/CommE2E/comm/actions/runs/10722767078/job/29734470192

Reviewers: varun, will

Reviewed By: varun

Subscribers: tomek

Differential Revision: https://phab.comm.dev/D13247
@yasali
Copy link

yasali commented Sep 6, 2024

I have tried below script on my unit test job, and after cleaning up the space and when I rerun the job, all Xcodes version are still there.

- name: Calculate initial disk space
 run: df -h

- name: Size of apps in Applications folder Before deletion
 run: |
   sudo du -sh /Applications/*

# We only use Xcode 15.4
- name: Remove unused applications
 run: |
   df -hI /dev/disk3s1s1
   sudo rm -rf /Applications/Xcode_14.3.1.app
   sudo rm -rf /Applications/Xcode_15.0.1.app
   sudo rm -rf /Applications/Xcode_15.1.app
   sudo rm -rf /Applications/Xcode_15.2.app
   sudo rm -rf /Applications/Xcode_15.3.app
   df -hI /dev/disk3s1s1

- name: Size of apps in Applications folder After deletion
 run: |
   sudo du -sh /Applications/*

- name: Clean Xcode derived data and caches
 run: |
   sudo rm -rf ~/Library/Developer/Xcode/DerivedData

- name: Delete unnecessary simulator files
 run: |
   sudo rm -rf ~/Library/Developer/CoreSimulator/Devices/*
   sudo rm -rf ~/Library/Developer/CoreSimulator/Caches/*

- name: Clean up iOS DeviceSupport files
 run: |
   sudo rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

- name: Check final disk space
 run: df -h

chandlerc added a commit to chandlerc/carbon-lang that referenced this issue Sep 9, 2024
This should mitigate the effects of a GitHub regression that reduced
space on these runners:
actions/runner-images#10511

After this, we're mostly fine, but builds that happen to compile enough
of the codebase can bump past it. Hopefully with this PR we'll have
plenty of space.
@chandlerc
Copy link

For other folks finding this...

Definitely bit our project too, and seems like a pretty sharp regression.

We found removing Xcode versions was very slow though and for limited space. The tip to remove the iOS simulators (and maybe only add the one you need) look much more promising. Happens that we're just testing on macOS, not iOS, so even better for us. In case folks want to see a full PR that adds this:
carbon-language/carbon-lang#4287

github-merge-queue bot pushed a commit to carbon-language/carbon-lang that referenced this issue Sep 9, 2024
This should mitigate the effects of a GitHub regression that reduced
space on these runners:
actions/runner-images#10511

After this, we're mostly fine, but builds that happen to compile enough
of the codebase can bump past it. With this PR we have over 50 GiB of
space which is more than we need.

See a test run here:
https://github.com/carbon-language/carbon-lang/actions/runs/10780743574
@actions actions deleted a comment from Anb111pip Sep 9, 2024
@actions actions deleted a comment from Anb111pip Sep 9, 2024
@rodperottoni
Copy link

rodperottoni commented Sep 10, 2024

Also ran into this issue. My actions are constantly failing unless I do some serious runner cleanup beforehand. Upon investigation, it seems like every Xcode folder in Applications has a duplicate with an extraneous _0 at the end.

Running: find /Applications -name "Xcode_*" -maxdepth 1 -mindepth 1

Outputs:

/Applications/Xcode_16.0.app
/Applications/Xcode_16.1.app
/Applications/Xcode_14.3.app
/Applications/Xcode_15.1.app
/Applications/Xcode_15.0.app
/Applications/Xcode_15.2.app
/Applications/Xcode_15.3.app
/Applications/Xcode_15.4.app
/Applications/Xcode_14.3.1.app
/Applications/Xcode_16.1_beta.app
/Applications/Xcode_15.1.0.app
/Applications/Xcode_16.0.0.app
/Applications/Xcode_15.3.0.app
/Applications/Xcode_15.4.0.app
/Applications/Xcode_15.2.0.app
/Applications/Xcode_16.1.0.app
/Applications/Xcode_16_beta_6.app
/Applications/Xcode_15.0.1.app

Is this expected? Why suddenly all versions have a sibling .0 clone?

@erik-bershel
Copy link
Contributor

Hey @rodperottoni!

It's just a symlink. It takes no space.

@erik-bershel
Copy link
Contributor

macOS-14 images without visionOS on board rolled out. It made free plenty of precious GB. We will continue to work on image optimisation and reorganisation of used space. At this point the free space issue should be resolved for the vast majority of users. I will not close this issue as a temporary solution was applied while a permanent one is still in development.

@salvatoreboemia
Copy link

salvatoreboemia commented Sep 26, 2024

I can confirm, maybe we could avoid to free up space by removing xcode in our Action?

Initial space mac os 14

Screenshot 2024-09-26 at 16 15 33

After clean up

Screenshot 2024-09-26 at 16 17 07

@erik-bershel
Copy link
Contributor

I can confirm, maybe we could avoid to free up space by removing xcode in our Action?

At your discretion. I think you can disable it for now to save execution time if the specified space is enough for you. I will notify you and other participants separately about all further changes as they happen.

@erik-bershel
Copy link
Contributor

👋

For those tracking these changes or encountering issues for the first time, here’s some context and clarification.

As you may know, we recently faced significant challenges where many users began running out of disk space during tests and builds on macOS-based runners. 😞 This issue was triggered by the inclusion of visionOS simulators in the latest Xcode builds. The root cause, however, lies in our policy of providing nearly all supported minor versions of Xcode on each macOS image, leading to steadily increasing disk usage as Apple’s ecosystem grows.

Here’s how we’ve approached resolving the issue so far:

  • Immediate action: We temporarily stopped pre-installing visionOS platform tools in Xcode on macOS-14 images.
  • Strategic adjustment: We introduced a policy to limit the number of major Xcode versions installed per macOS image, alongside reinstating visionOS tools for supported Xcode versions. This aimed to free up significant disk space. [doc] Update Xcode support policy #10876

However, we’ve discovered that some projects rely on multiple major versions of Xcode simultaneously, making these strict measures overly restrictive. This prompted us to refine our strategy, prioritising functionality alongside disk space optimisation.

Current Strategy 📏

Our updated approach balances reducing installed Xcode versions with maintaining runner usability:

  1. macOS-14 images:
  • Will include all minor releases of Xcode 15 with the full platform tools suite (as before).
  • Will now also include two minor releases of Xcode 16 (excluding visionOS tools). These will follow a “last two” principle, with the oldest replaced by the newest as updates are released. Beta versions will not be included. [macOS] Add Xcode16 back to macOS14 images #10962
  1. macOS-15 images:
  • Will include all minor releases of Xcode 16 with the full platform tools suite (as before).
  • Will also include the latest available release of Xcode 15 with the full platform tools suite. [macOS] Add Xcode 15.4 to macOS-15 #11023
  1. Disk Space and Future Adjustments:
  • Currently, macOS-14 images have approximately 60 GB of free space. However, this is not a guaranteed figure and may decrease over time.
  • When free space approaches 30 GB, we will reassess our policies and toolsets to ensure compliance with our promised minimum of 14 GB of free space.
  • macOS-15 images are not currently impacted by this issue. However, with future Xcode updates, policies may need to be revisited. 🤷‍♂️

Recommendations 🦮

  • If your workflows depend on visionOS, we recommend switching to macOS-15 images.
  • If your tasks require significant disk space, consider preparing the runner by removing unnecessary large components before starting your workflows.

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

No branches or pull requests