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

Cache on windows runner takes a long time to load #495

Open
2 of 5 tasks
nikpivkin opened this issue Aug 14, 2024 · 2 comments
Open
2 of 5 tasks

Cache on windows runner takes a long time to load #495

nikpivkin opened this issue Aug 14, 2024 · 2 comments
Labels
feature request New feature or request to improve the current logic

Comments

@nikpivkin
Copy link

nikpivkin commented Aug 14, 2024

Description:
We run tests on runners with different OS using matrix. On ubuntu and macos the cache loads in an acceptable time (about 30 seconds), but on windows the cache loads for almost 12 minutes, which is very long. I didn't notice any windows related restrictions in the Readme.

Action version:
actions/setup-go@v5

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:
'1.22'

Repro steps:
Action: https://github.com/aquasecurity/trivy-aws/actions/runs/10383103541/job/28747388089?pr=210

Expected behavior:
The cache loads quickly.

Actual behavior:
The cache takes a long time to load.

@priyagupta108
Copy link
Contributor

Hello @nikpivkin ! Thank you for reporting this!
We will investigate the issue and get back to you as soon as we have updates.

@gowridurgad
Copy link

Hi @nikpivkin, Here are few reasons why windows takes more time than ubuntu and macos:

System Architecture: Windows has a different system architecture compared to Unix-based systems like Ubuntu and macOS, often resulting in higher overhead for tasks involving disk I/O operations.
File System Differences: The NTFS file system used by Windows is generally slower for certain types of operations compared to ext4 (used by Ubuntu) and APFS (used by macOS).
Disk I/O Handling: Windows tends to have more background processes and services that can interfere with disk I/O operations, leading to longer cache loading times.

After analysing the issue, we concur that the current duration for both installation and cache reloading isn't ideal. The cache reloading process should indeed be optimized for enhanced speed. We appreciate your feedback and will contemplate this as a potential feature request for future improvements rather than a bug.

@gowridurgad gowridurgad added feature request New feature or request to improve the current logic and removed bug Something isn't working labels Sep 2, 2024
@gowridurgad gowridurgad removed their assignment Sep 2, 2024
bflad added a commit to speakeasy-api/speakeasy that referenced this issue Dec 3, 2024
Reference: actions/setup-go#495

Previously, it could take up to 10 minutes to download and unarchive the cache on Windows runners.
bflad added a commit to speakeasy-api/speakeasy that referenced this issue Dec 3, 2024
… CI (#1133)

Reference: actions/setup-go#495

This improves PR testing from >15 minutes to <5 minutes by using larger
runners (in runner group so we can tune them without adjusting workflow
configuration) and by disabling setup-go caching on Windows. Previously,
it could take up to 10 minutes to download and unarchive the setup-go
cache on Windows runners due to an acknowledged issue. While this could
potentially introduce transient network issues downloading the Go
modules from Google's proxies, those issues are generally pretty rare in
my experience. We could alternatively change the module cache
environment variables on Windows to point at the second hard drive on
the runner, but that seemed more likely to break at some point outside
our control. Ideally GitHub will fix the setup-go action and we'll just
remove the Windows-specific `cache: false` after upgrading.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

3 participants