Disable incremental build using transitive digests

[haenah]

• Dart SDK Version: 3.3.3
• Package: build_resolvers 2.4.2

I recently implemented a CI/CD system using GitHub Actions to deploy our company's Flutter app. However, running build_runner takes an immense amount of time. Therefore, I investigated which builders were causing the delay. Through performance tracking of build_runner, I discovered that build_resolvers|transitive_digests was consuming time by digesting all package dependencies, particularly in the CI environment. I speculate this slowdown is due to the lack of dedicated digest computing hardware on GitHub-hosted runner machines compared to Apple Silicon Mac(It gets 20 times slower on github-hosted runner, which is almost 5 minutes). Implementing a lightweight build resolver that omits generating transitive digests could significantly reduce build times in environments not requiring incremental builds, especially as CI environments. I welcome your insights. Are there any reasons why digesting is mandatory even in environments that do not necessitate incremental builds?

[jakemac53]

You should be able to try just disabling that builder - but most likely it will make your build slower and not faster (digests will end up being computed still, just later on by a different builder, and multiple times). You can try disabling it by adding a build_resolvers.build.yaml file in your package which is empty.

We don't have a mode for doing non-incremental builds. I don't believe it would help all that much, and it would probably be quite involved to add, digests are a pretty core piece of the package.

Note as well that you can try enabling caching of the .dart_tool/build directory, which should allow you to get incremental builds on CI. This is probably your best path toward faster CI builds - especially if you check in your pubspec.lock file.

[haenah]

@jakemac53 Thanks for your opinion! I'll try out approaches you suggested.

[davidmorgan]

I'll be looking into transitive digest performance as part of #3811, so I'll close this one in favour of that.