Skip to content

Conversation

@keyonghan
Copy link
Contributor

This is part of flutter/flutter#51807

We will support commits following different branches. Existing logic to push build status to github doesn't recognize branch difference. It will calculate build status based on latest commits of master (default), and push the status to all PRs in github.

The change here fixes above issue. It will update PRs of a specific branch based on the build status calculated according to that branch's commits.

final List<Branch> branches = await getBranches(
config, branchHttpClientProvider, log, gitHubBackoffCalculator);
for (Branch branch in branches) {
final BuildStatus buildStatus = await buildStatusProvider
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be an expensive operation. I presume that we will only add release branches, and never remove any.

We should look into a way of only updating branches that had changes. I imagine once we have 100+ branches we do not want to be making this many Datastore reads on a cron job

Copy link
Contributor

Choose a reason for hiding this comment

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

One marginal improvement I have is maybe we can update the build status provider to use the cache?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a good point. I added this as a todo to improve the performance. Now prefer to have everything ready to run an e2e test first.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

SGTM

for (Branch branch in branches) {
final BuildStatus buildStatus = await buildStatusProvider
.calculateCumulativeStatus(branch: branch.name);
final GitHub github = await config.createGitHubClient();
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this GitHub logic be moved into GitHubService? Seems repetitive to have GitHubService and a GitHub client in the same request handler.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

GitHubService is used to provide github queries that are not supported by GitHub client itself.

Copy link
Contributor

Choose a reason for hiding this comment

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

Couldn't this get the github client from the service instead then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hit some error in test by using github client instead before. Now managed to solve any hit issues.

'Updating status of ${slug.fullName}#${pr.number} from ${update.status}');
final CreateStatus request = CreateStatus(buildStatus.githubStatus);
request.targetUrl =
'https://flutter-dashboard.appspot.com/build.html';
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: This gets redirected to https://flutter-dashboard.appspot.com/#/build

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

final CreateStatus request = CreateStatus(buildStatus.githubStatus);
request.targetUrl =
'https://flutter-dashboard.appspot.com/build.html';
request.context = 'flutter-build';
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Can we move this and the description to the config?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Comment on lines +106 to +115
final int maxEntityGroups = config.maxEntityGroups;
for (int i = 0; i < updates.length; i += maxEntityGroups) {
await datastore.db
.withTransaction<void>((Transaction transaction) async {
transaction.queueMutations(
inserts: updates.skip(i).take(maxEntityGroups).toList());
await transaction.commit();
});
}
log.debug('Committed all updates');
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused at what this is doing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

With such a nitty detail to datastore, it would be cleaner to move this code to the Datastore service and add documentation to why it's needed. Copying that explanation is a good start, but i'm still confused as to why pushing build status to github can handle Datastore writes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have a status entity in datastore to denote how many updates we have made so for for existing PRs. So whenever we push status to github, we write corresponding update index.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds like it would be good to document it in the code then :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a brief documentation. Thank you!

expect(log.records.where(hasLevel(LogLevel.ERROR)), isEmpty);
});
});

Copy link
Contributor

Choose a reason for hiding this comment

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

There should be a test where there are multiple branches (e.g. master and dev) to make sure both get updates pushed to them

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.

Copy link
Contributor

@CaseyHillers CaseyHillers left a comment

Choose a reason for hiding this comment

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

LGTM. Just some documentation left to be addressed

Comment on lines +106 to +115
final int maxEntityGroups = config.maxEntityGroups;
for (int i = 0; i < updates.length; i += maxEntityGroups) {
await datastore.db
.withTransaction<void>((Transaction transaction) async {
transaction.queueMutations(
inserts: updates.skip(i).take(maxEntityGroups).toList());
await transaction.commit();
});
}
log.debug('Committed all updates');
Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds like it would be good to document it in the code then :)


String get cqLabelName => 'CQ+1';

String get flutterBuild => 'flutter-build';
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Document what these are used for

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.

@keyonghan keyonghan merged commit 5ba312d into flutter:master Mar 23, 2020
@keyonghan keyonghan deleted the build_status_branch branch March 13, 2024 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants