Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore: optimize CI setup time on Windows #17666

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

Merged
merged 1 commit into from
May 5, 2025

Conversation

hugodutka
Copy link
Contributor

@hugodutka hugodutka commented May 3, 2025

This PR focuses on optimizing go-test CI times on Windows. It:

  • backs the $RUNNER_TEMP directory with a RAM disk. This directory is used by actions like cache, setup-go, and setup-terraform as a staging area
  • backs GOCACHE and GOMODCACHE with a RAM disk
  • backs $GITHUB_WORKSPACE with a RAM disk - that's where the repository is checked out
  • uses preinstalled Go on Windows runners
  • starts using the depot Windows runner

From what I've seen, these changes bring test times down to be on par with Linux and macOS. The biggest improvement comes from backing frequently accessed paths with RAM disks. The C drive is surprisingly slow - I ran some performance tests with fio where I tested IOPS on many small files, and the RAM disk was 100x faster.

Additionally, the depot runners seem to have more consistent performance than the ones provided by GitHub.

@hugodutka hugodutka changed the title chore: optimize go setup time on Windows in CI chore: optimize CI setup time on Windows May 3, 2025
@hugodutka hugodutka force-pushed the hugodutka/test-go-windows-optimization branch 17 times, most recently from 57b3159 to 7ef265b Compare May 5, 2025 10:46
@hugodutka hugodutka marked this pull request as ready for review May 5, 2025 11:08
@hugodutka hugodutka requested a review from deansheather May 5, 2025 11:08
# a separate repository to allow its use before actions/checkout.
- name: Setup RAM Disks
if: runner.os == 'Windows'
uses: coder/setup-ramdisk-action@fbbd000cb83aff384a5f457c9073135189a4cf55
Copy link
Member

Choose a reason for hiding this comment

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

This should probably check the SHA256 of the downloaded files for extra safety.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

# RUNNER_TEMP should be backed by a RAM disk on Windows if
# coder/setup-ramdisk-action was used
export GOCACHE_DIR="$RUNNER_TEMP""\go-cache"
export GOMODCACHE_DIR="$RUNNER_TEMP""\go-mod-cache"
Copy link
Member

Choose a reason for hiding this comment

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

Does anything go in GOPATH? GOMODCACHE is under GOPATH by default, so it seems like it would be better to just move the entire GOPATH to the ramdisk instead perhaps

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I’ve now backed GOPATH with a RAM disk too. It doesn’t seem to boost performance, though. I’m wondering if some writes are happening in the background to another path on C:. For example, unpacking archives in actions/cache takes way more time than I’d expect, even though it extracts onto a RAM disk.

@hugodutka hugodutka force-pushed the hugodutka/test-go-windows-optimization branch 3 times, most recently from c10b504 to a78e91c Compare May 5, 2025 12:07
@hugodutka hugodutka merged commit 87f4535 into main May 5, 2025
36 checks passed
@hugodutka hugodutka deleted the hugodutka/test-go-windows-optimization branch May 5, 2025 12:26
@github-actions github-actions bot locked and limited conversation to collaborators May 5, 2025
@hugodutka
Copy link
Contributor Author

For future reference, this helps unblock #15109.

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

Successfully merging this pull request may close these issues.

3 participants