-
Notifications
You must be signed in to change notification settings - Fork 104
Tree Build Status changes the AppBar color #452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6504cf5
887de76
8ac0814
8a2ec49
b6d3d2e
62dad09
518a5b9
ab3cc80
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -46,6 +46,48 @@ class AppEngineCocoonService implements CocoonService { | |
| return _commitStatusesFromJson(jsonResponse['Statuses']); | ||
| } | ||
|
|
||
| @override | ||
| Future<bool> fetchTreeBuildStatus() async { | ||
| /// This endpoint returns JSON {AnticipatedBuildStatus: [BuildStatus]} | ||
| http.Response response = | ||
| await _client.get('$_baseApiUrl/public/build-status'); | ||
|
|
||
| if (response.statusCode != HttpStatus.ok) { | ||
| throw HttpException( | ||
| '$_baseApiUrl/public/build-status returned ${response.statusCode}'); | ||
| } | ||
|
|
||
| Map<String, Object> jsonResponse = jsonDecode(response.body); | ||
|
|
||
| if (!_isBuildStatusResponseValid(jsonResponse)) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Better log this response, otherwise when we see the exception, we don't know why/how it's malformed.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This will print the error to a local console. Should we think about implementing a logging system such as Firebase Crashlytics so users don't have to report these errors?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue with logging to console is that the #1 usecase for this will be the TVs in the immediate aread.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not only the TV, I always have the build dashboard open on my chrome, so it would be nice to know the errors when they happen.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When errors happen on the TV, we just need to know an error is occurring. We do not need to know what the error is. The only time we would want to know what the error is on the TV is when we can't reproduce it on any other device. However, in that case the issue is most likely with the TV and not the application. Thus, showing a generic error UI would indicate that someone needs to check what is going on by opening the dashboard on their computer to investigate further. |
||
| throw HttpException( | ||
| '$_baseApiUrl/public/build-status had a malformed response'); | ||
| } | ||
|
|
||
| return jsonResponse['AnticipatedBuildStatus'] == "Succeeded"; | ||
| } | ||
|
|
||
| /// Check if [Map<String,Object>] follows the format for build-status. | ||
| /// | ||
| /// Template of the response it should receive: | ||
| /// ```json | ||
| /// { | ||
| /// "AnticipatedBuildStatus": "Succeeded"|"Failed" | ||
| /// } | ||
| /// ``` | ||
| bool _isBuildStatusResponseValid(Map<String, Object> response) { | ||
| if (!response.containsKey('AnticipatedBuildStatus')) { | ||
| return false; | ||
| } | ||
|
|
||
| String treeBuildStatus = response['AnticipatedBuildStatus']; | ||
| if (treeBuildStatus != 'Failed' && treeBuildStatus != 'Succeeded') { | ||
| return false; | ||
| } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: it's more readable to write this in a positive way: "In general checking the presence or absence of a positive is simpler for readers to understand than checking the presence or absence of a negative."
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For future reference: Testing on the Toilet #530: Improve Readability with Positive Booleans The reason I chose this way was to have cases that returned false next to each other, instead of case 1 returns false, case 2 returns true, final case returns false. I wanted to try and reduce the cognitive switching on the return value. |
||
|
|
||
| return true; | ||
| } | ||
|
|
||
| List<CommitStatus> _commitStatusesFromJson(List<Object> jsonCommitStatuses) { | ||
| assert(jsonCommitStatuses != null); | ||
| // TODO(chillers): Remove adapter code to just use proto fromJson method. https://github.com/flutter/cocoon/issues/441 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to "Succeeded" and "Failed", it's useful to know how outdated is the information.