13d2219efd
The flutter tool will now download and use an `engine_stamp.json` file to determine the engine version, content hash, build date, and commit date. The file is treated as a new `DevelopmentArtifact.informative` and is fetched before flutterVersion is used. This ensures we have build information for a clean checkout with no bin/cache folder. Users that download from flutter.dev will have engine_stamp.json, so its a no-op. This change provides support for content hashed engine artifacts, who's revision (the hash) is not a git commit sha. A side benefit is "git" is only used at build time to extract this information. > [!NOTE] > Content hashed artifacts are not enabled yet for downloads; bin/internal/engine.version (releases) and the shell updaters still look for the git commit sha. One can test this out by setting `FLUTTER_PREBUILD_ENGINE_VERSION` to the content hash.
Integration tests
These tests are not hermetic, and use the actual Flutter SDK. While
they don't require actual devices, they run flutter_tester to test
Dart VM and Flutter integration.
Use this command to run (from the flutter_tools directory):
../../bin/cache/dart-sdk/bin/dart run test test/integration.shard
You need to have downloaded the Dart SDK in your Flutter clone for this
to work. Running ../../bin/flutter will automatically download it.
Coverage exclusion
These tests are expensive to run and do not give meaningful coverage
information for the flutter tool (since they are black-box tests that
run the tool as a subprocess, rather than being unit tests). For this
reason, they are in a separate shard when running on continuous
integration and are not run when calculating coverage.
Adding new test files
When adding a new test file make sure that it ends with _test.dart, or else it will not be run.