It can be fast:

Perhaps consider not using dotnet install script or is the option to contribute a fix to dotnet install script?

Hi @jetersen, we will try to resolve this problem.

Hi Team - any news on this?

Hello @PureKrome,

So far no updates

The problem is not reproduced anymore.

Based on multiple runs, the action does not take more than 15 seconds.
https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6729109167

Most probably, the root cause of the problem was an infrastructure issue that has currently been resolved.

In case the problem reoccurs, the solution is to avoid bulk copying to the OS drive, similar to the workaround applied for the same problem in the actions/setup-go: actions/setup-go#393

@jetersen did it help?

@dsame I do not agree with the assessment that it is not reproducible 😓
Even with cache available Windows Server 2022 is still 20 seconds slower.
Creating the cache is still 1 minute longer than time of Ubuntu when running Windows Server 2022.

So definitely an improvement but I feel like windows can perform better.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736238225
https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736262624

I don't think it is fair to say look it is fixed for the actions/setup-dotnet when we are talking about a simple if check to see if .NET 6 is already available on the actions runner image 😓

Testing with .NET 8 preview shows ubuntu with 7 seconds vs +30 seconds sometime a little less. For actions/setup-dotnet.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736383956/job/18311632176

While this issue remains open: #141 this will definitely not improve 😢

Thank you @jetersen for pointing out .NET 8 issue, it's confirmed

https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6742358650/job/18328332807

@dalyIsaac interesting approach, does that really save that much 🤔

I'm fairly happy with the gains I've seen, but admittedly I didn't conduct a very rigorous study.

Hello @jetersen

The quick fix is to set environment variable DOTNET_INSTALL_DIR to the value pointing to some path on the "D:" drive.

akv-demo/dotnet.restore.slow.github.action@45e801a#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR15

This workaround is proven to solve the problem https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6768243557/job/18392290993 and can be used until the action fix is available

@dsame perhaps some of these fixes should be raised with @actions/runner-images? I assume we are hitting similar IO restrictions on the Windows images as this affects all windows based hosted runners 🫠

Hello @jetersen, generally it is a good idea but i doubt any of actions team can solve the problem with the infrastructure and most probably the infrastructure problem is not expected to be solved in the acceptable timeframe.

but i doubt any of actions team can solve the problem with the infrastructure

why is this? because these are 2 independent teams within GH and even though the actions team could make some changes based on this thread (which would benefit all users, by default) ... the intra-team still need to also do some changes but you're suggesting that this is a low priority so .. they go 'meh' ?

Created actions/runner-images#8755 in hoping that we can find a generic solution. I was hoping they could simply change the disk setup on the windows packer scripts 🤔

hi