* Support release/debug flavors of flutter_patched_sdk
* Use [anyNamed] instead of [any] for mocking named arguments
* Fix use of local engine in release mode
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.
* Remove many timeouts.
These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.
* Get the attach tests to pass.
* Apply review comments from Todd
* More review comment fixes
* Put back the extended timeouts here now that I know why we have them...
* Added '--check-for-remote-artifacts' option for Flutter Doctor.
This option takes a Flutter engine revision and issues HEAD requests to
determine whether or not artifacts for the provided engine revision are
available from cloud storage. This functionality is needed for the Dart
SDK autoroller to avoid creating a PR to roll the engine into the
framework while artifacts haven't finished building, which would cause
Cirrus tests to fail.
Disallow calling stop() or cancel() multiple times. This means that
when you use startProgress you have to more carefully think about what
exactly is going on.
Properly cancel startProgress in non-ANSI situations, so that
back-to-back startProgress calls all render to the console.
Disallow calling stop() or cancel() multiple times. This means that
when you use startProgress you have to more carefully think about what
exactly is going on.
Properly cancel startProgress in non-ANSI situations, so that
back-to-back startProgress calls all render to the console.
* Use already downloaded dart sdk for frontend_server.
This is follow-up to https://github.com/flutter/flutter/pull/14610
* Remove reference to engine dart-sdk from artifacts
* Remove unused imports
* WIP to switch back to solution where dart sdk is downloaded into bin/cache/dart-sdk, but it is 'flutter precache -a' that can download all dart sdks for other platforms under bin/cache/artifacts/engine/<platform>/dart-sdk
* Download all dart sdks when 'flutter precache -a'
* Revert "Revert "Make artifact downloading more robust for flaky networks" (#13995)"
This reverts commit 33d8a03545.
* Use subdirectories to organize cached files
* Fix unauthorized import
* Revert "Change github readme links to be served by github (#13929)"
This reverts commit fd516d9538.
* Revert " Rename SemanticsFlags to SemanticsFlag (#13994)"
This reverts commit 24e3f70536.
* Revert "Make artifact downloading more robust for flaky networks (#13984)"
This reverts commit 4d37e03e1d.
* First version
* Add a clarifying comment
* Add verify to ZipDecoder.decodeBytes call
* Review comments
* Need OS Error for missing files
* FileSystemException, not OSError.
Add support for configuring the base storage URL for Flutter's
artifacts. If FLUTTER_STORAGE_BASE_URL is set, use it instead of
storage.googleapis.com.
The pub server can be overridden by setting PUB_HOSTED_URL.
Rather than depending on android.googlesource.com for hosting the gradle
wrapper, host our own copy on storage.googleapis.com (along with our
other artifacts).
Also added a script to repackage AOSP's version into ours, in case we
ever need to update it.
Addresses the gradle wrapper part of #11681.
* Enable Hot Reload on Windows (backed by gen_snapshot)
\o/
Two caveats:
* Hot Reload on Windows is slower than on other platforms because gen_snapshot is slower then sky_snapshot
* We currently cannot hot reload projects with spaces in the path
* enable tests
The zip files downloaded from cloud storage are not clearly separated
into engine artifacts and tools anyways.
Also, because of this unclear separation, we were downloading
`linux-x64/artifacts.zip` twice before.
This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.
This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.
