Skip to content

Report commands that resulted in success or failure #34288

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

Merged
merged 4 commits into from
Jun 13, 2019

Conversation

blasten
Copy link

@blasten blasten commented Jun 11, 2019

Description

Success and failure events at the command level.

Related Issues

Fixes #33779

Tests

I added the following tests:

  • 2 tests in flutter_command_test.dart

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I signed the CLA.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
  • No, this is not a breaking change.

@blasten blasten requested review from xster and zanderso June 11, 2019 22:47
@blasten blasten force-pushed the log_success_failure branch from 1b627fd to cacfd98 Compare June 11, 2019 22:53
@blasten blasten force-pushed the log_success_failure branch from cacfd98 to 281bc6d Compare June 11, 2019 23:51
@@ -316,10 +315,7 @@ class AttachCommand extends FlutterCommand {
result = await runner.attach();
assert(result != null);
}
if (result == 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a meta-point (this might have been there from before), have we been splitting our flutter attach analytics volume between flutterUsage.sendEvent/events and flutterUsage.sendCommand/screen?

If so, we might want to consolidate them in one place and make sure the go/flutter-dash graph reflects it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw the comment. I agree that given the flutterUsage.sendEvent/events mechanism, it makes sense to add global annotations to all of them. I was asking about the semantics of FlutterCommands such as flutter attach that both send flutterUsage.sendCommand/screen in FlutterCommand.verifyThenRunCommand and a flutterUsage.sendEvent/events in FlutterCommand.run.

There was a bit of an existing pattern already going on where events are being used as smaller inner acts such as hot restarting and screens being used for bigger outer flutter CLI acts such as run, attach etc.

1- should we keep that semantic separated, and
2- should we also log success/failure in flutterUsage.sendCommand/screens as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, in my comment in the other PR, I missed the sendCommand call in verifyThenRunCommand. If it makes more sense to add a success/failure parameter to the sendCommand there, then you could put the runCommand() in a try {} except {} finally {} with the sendCommand in the finally. Similar pattern as above in run().

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now centralized. PTAL

@Piinks Piinks added the tool Affects the "flutter" command-line tool. See also t: labels. label Jun 12, 2019
@blasten blasten requested a review from xster June 13, 2019 00:21
@blasten blasten force-pushed the log_success_failure branch from 52b495e to bee864b Compare June 13, 2019 01:22
@blasten blasten force-pushed the log_success_failure branch from bee864b to 93e8464 Compare June 13, 2019 04:55
Copy link
Member

@xster xster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@zanderso zanderso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

@blasten blasten merged commit afdc783 into flutter:master Jun 13, 2019
@blasten blasten deleted the log_success_failure branch June 13, 2019 17:27
kiku-jw pushed a commit to kiku-jw/flutter that referenced this pull request Jun 14, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
tool Affects the "flutter" command-line tool. See also t: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Log success/failure for every command
5 participants