You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once github/roadmap#826 is available, let's use custom VM images for CI builds.
The image used for .NET builds should contain all build dependencies preinstalled, as well as an OSOCE source built that'll be updated on checkout (or if that's not possible, then re-cloned, but still, we'd have the NuGet and NPM caches warm). Perhaps saving OSOCE after also a test run would be useful, to let the UI Testing Toolbox install its dependencies (smtp4dev, Zap) too.
This should be regenerated when OSOCE dev changes; most possibly, after every dev commit it'd be wasteful, but perhaps once every day if there are new dev commits.
Once this works with package caches, package caching in the build workflow can be disabled.
If this works out well, we can introduce it in all other projects of ours too.
This should be regenerated when OSOCE dev changes; most possibly, after every dev commit it'd be wasteful, but perhaps once every day if there are new dev commits.
Last time I built the official GH image it was around 4-5 hours I think, but we can reuse that image and build our own on top of that. Based on what I know now, our own image build should be around 10 minutes or less, but we can further refine the conditions and only regenerate it when the OSOCE NuGetTest folder/solution is updated.
Once github/roadmap#826 is available, let's use custom VM images for CI builds.
The image used for .NET builds should contain all build dependencies preinstalled, as well as an OSOCE source built that'll be updated on checkout (or if that's not possible, then re-cloned, but still, we'd have the NuGet and NPM caches warm). Perhaps saving OSOCE after also a test run would be useful, to let the UI Testing Toolbox install its dependencies (smtp4dev, Zap) too.
This should be regenerated when OSOCE
dev
changes; most possibly, after everydev
commit it'd be wasteful, but perhaps once every day if there are newdev
commits.Once this works with package caches, package caching in the build workflow can be disabled.
If this works out well, we can introduce it in all other projects of ours too.
Related:
Jira issue
The text was updated successfully, but these errors were encountered: