[flutter-gold] Support unified check run Dashboard Checks in push_gold_status_to_github (#5139) Fixes https://github.com/flutter/flutter/issues/191483 As detailed in the issue, the rollout of unified check runs replaced individual shard check runs with `Dashboard Checks`. Because `PushGoldStatusToGithub` matched against a hardcoded list of legacy shard names, golden status updates and triage labels stopped triggering on PRs. This PR adds `'dashboard checks'` to the recognized check run list. Under the unified flow, individual shard check runs are no longer published to GitHub. While we could theoretically inspect individual shards by querying Firestore `PresubmitGuard` records, doing so is unnecessary. `Dashboard Checks` only completes once all scheduled presubmit builds have finished, and tests upload golden image digests directly to Skia Gold as they run. When `Dashboard Checks` completes, Skia Gold already knows whether golden tests ran and whether any unexpected images were produced. For PRs that do not touch goldens (or do not run golden tests at all), Skia Gold returns zero untriaged images, so Cocoon cleanly marks `flutter-gold` as `SUCCESS` without posting comments or applying labels. Skipping Firestore queries keeps `PushGoldStatusToGithub` simple, fast, and stateless against GitHub and Gold. Added unit tests in `push_gold_status_to_github_test.dart` for in-progress, untriaged, and clean `Dashboard Checks` states. cc @ievdokdm @jtmcdole ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md
Cocoon is a Dart App Engine custom runtime (backend) with a frontend of Flutter apps (build and repository dashboard). Cocoon coordinates and aggregates the results of flutter/flutter builds.
It is not designed to help developers build Flutter apps.
Cocoon is not a Google product.
The server is driven by commits made to https://github.com/flutter/flutter repo. It periodically syncs new commits. If you need to manually force a refresh, query https://flutter-dashboard.appspot.com/api/refresh-github-commits.
You will need to be authenticated with Cocoon to do this.
Cocoon has several components:
A server, which coordinates everything. This is a Dart App Engine application. If you have never used that before, you may want to peruse the samples for Dart App Engine. The server is found in app_dart.
A Flutter app (generally used as a Web app) for the build dashboards. The dashboard is found in dashboard.
Cocoon creates a checklist for each Flutter commit. A checklist is made of multiple tasks. Tasks are performed by LUCI bots.
First, set up a Flutter development environment. This will, as a side-effect, provide you with a Dart SDK. Your life will be easier if you add that (.../flutter/bin/cache/dart-sdk/bin/) to your path.
To update the production server, you will need the Google Cloud SDK. Since there is no Dart SDK, we just use the command line tools.
All the commands in this section assume that you are in the app_dart/ directory.
dart bin/local_server.dart
This will output Serving requests at 0.0.0.0:8080 indicating the server is working.
New requests will be logged to the console.
To run live tests, build the app, and provide instructions for deploying to Google App Engine, run this command:
dart dev/deploy.dart --project {PROJECT} --version {VERSION}
You can test the new version by accessing {VERSION}-dot-flutter-dashboard.appspot.com in your browser. If the result is satisfactory, the new version can be activated by using the Cloud Console UI: https://console.cloud.google.com/appengine/versions?project=flutter-dashboard&serviceId=default
--profile: Deploy a profile mode of dashboard application for debugging purposes.
--ignore-version-check: Ignore the version of Flutter on path (expects to be relatively recent)
The dashboard application will use dummy data when it is not connected to the server, so it can be developed locally without a dev server.
To run the dashboard locally, go into the dashboard directory and run flutter run -d chrome --dart-define=FAKE_AUTH=true. The dashboard will be served from localhost (the exact address will be given on the console); copy the URL into your browser to view the application. (The dashboard should also be able to run on non-Web platforms, but since the Web is our main target that is the one that should generally be used for development.)
You can run flutter packages upgrade to update the dependencies. This may be necessary if you see a failure in the dependencies.