-
So during the whole setup of my actions, I had no idea there were any limits to overall usage since the documentation only talked about concurrency limits, not total time limits. I got surprise billed since the default billing option is unlimited. While annoying, that’s fine, it was only a few bucks. My real questions is: what can we do to optimize our build times? I’m definitely going to remove some of the extraneous platforms now that I know about it, however there’s a few things going on that are outside my ability to control:
I think for the short term I’ll collapse seperate builds (debug,release,retail) into a single run so I the vulkan and deven costs don’t hit me too hard, but what can we do about some of these redundant, fixed costs in the long term? Is there any way to iterate on the build config without eating too much time other than disabling everything while iterating? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
For 1, you just have to research things that generally help build speed locally. If you’re building C++/C consider looking into precompiled headers, and/or investigate building with Clang (in my experience the Clang compiler ends up being much faster than MSVC) For 2, you should try to determine what devenv is doing and where it’s putting artifacts that incur the startup cost, and then modify your workflow to try to cache those locations. Unfotunately the caching right now is very limited (2 GB per repository, which is easy to blow past for a Windows C++/C build toolchain). On the other hand if this startup time is orthogonal to your actual project configuration, maybe file an issue here: https://github.com/actions/virtual-environments suggesting that they pre-run the command on the Windows build host images. For 3, follow this issue: actions/runner-images#18 It really seems to me that Vulkan should be part of the default build image. For 4, you might try looking into the self-hosting functionality. You could self-host on your own development machine and then do the bulk of the workflow development without incurring any cost, and only switch back to the Github Actions VMs at the end to ensure that it still works or debug any remaining issues. Unfortunately Github Actions doesn’t really provide any means of reproducing the build environment / installed software that they setup, so that can be a source of bugs trying to run the same workflow between a local machine and the GA VMs. |
Beta Was this translation helpful? Give feedback.
-
Thanks for all the responses.
|
Beta Was this translation helpful? Give feedback.
For 1, you just have to research things that generally help build speed locally. If you’re building C++/C consider looking into precompiled headers, and/or investigate building with Clang (in my experience the Clang compiler ends up being much faster than MSVC)
For 2, you should try to determine what devenv is doing and where it’s putting artifacts that incur the startup cost, and then modify your workflow to try to cache those locations. Unfotunately the caching right now is very limited (2 GB per repository, which is easy to blow past for a Windows C++/C build toolchain). On the other hand if this startup time is orthogonal to your actual project configuration, maybe file an issue he…