Skip to content

Conversation

@mdebbar
Copy link
Contributor

@mdebbar mdebbar commented Dec 7, 2021

Add a cron entry to send gold status to flutter/engine PRs that run web engine tests.

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

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

This will need to also update the URLs/messages in push_gold_status_to_github.dart and config.dart, currently they point to the framework instance of Gold, I think you will want them to point to the engine instance.

The pullRequestChecksQuery is also specific to flutter/flutter. I think this needs a bit more refactoring.

Tests should be easy, you can probably just copy-paste all of the framework version of these tests, and change the repo to flutter/engine to make sure everything is working: https://github.com/flutter/cocoon/blob/main/app_dart/test/request_handlers/push_gold_status_to_github_test.dart

Comment on lines 26 to 28
- description: sends pr-specific gold status to GitHub to annotate engine PRs and commits
url: /api/push-gold-status-to-github?repo=flutter/engine
schedule: every 5 minutes
Copy link
Contributor

Choose a reason for hiding this comment

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

Having separate cron jobs are probably less ideal.
Gold already has a very tight budget for the requests we make to it, so if these were running simultaneously, we might go over.
We should do this more like check_for_waiting_pull_requests.dart, with one cron job running through the supported repos.

Here is where that is happening:
https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/request_handlers/check_for_waiting_pull_requests.dart#L44

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 send a separate request to Gold for each PR, right? If that's the case, then the number of cron jobs doesn't matter. If there are 10 PRs in flutter and 10 PRs in the engine, we'll be sending 20 requests to Gold regardless of whether we have a single cron job or separate ones. I might be missing something here, so please correct me if I'm wrong :)

Copy link
Contributor

@Piinks Piinks Dec 7, 2021

Choose a reason for hiding this comment

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

We send a separate request to Gold for each PR, right?

We do, but one at a time.

There is a strict time threshold on those Gold endpoints. So the quantity does not matter, 10 framework + 10 engine PRs = 20, but if they are running in parallel like this, they could max out that rate limit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looking at the code, I see the requests being made sequentially anyway (unless I'm misunderstanding that code):

await for (PullRequest pr in gitHubClient.pullRequests.list(slug)) {
// Get last known Gold status from datastore.
final GithubGoldStatusUpdate lastUpdate = await datastore.queryLastGoldUpdate(slug, pr);

I'm happy to unify the cron jobs into one. Just trying to fully understand the reason behind it :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, they are done sequentially. But if you have two cron jobs, you will have two running simultaneously.

It is the requests we make to the Gold service itself (not github or the datastore) that are so restricted.

Uri.parse('https://flutter-gold.skia.org/json/v1/changelist_summary/github/${pr.number}');

Since it is a separate Gold instance, it may not be a problem, but it causes a lot of issues if we hit that rate limit.
I never noticed the build status were separate cron jobs, so if it fits the pattern and does not put us over the limit, I am fine with keeping them separate. :)

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.

Makes perfect sense now, thanks for explaining!

@mdebbar
Copy link
Contributor Author

mdebbar commented Dec 7, 2021

Tests should be easy, you can probably just copy-paste all of the framework version of these tests, and change the repo to flutter/engine to make sure everything is working: https://github.com/flutter/cocoon/blob/main/app_dart/test/request_handlers/push_gold_status_to_github_test.dart

I wanted to first send the PR to make sure I'm on the right path before I add/update tests.

@mdebbar
Copy link
Contributor Author

mdebbar commented Dec 7, 2021

@Piinks there's a check for master here:

I'm gonna change it to:

if (pr.base!.ref != 'master' || pr.base!.ref != 'main') {

Does that sound good to you?

@Piinks
Copy link
Contributor

Piinks commented Dec 7, 2021

I wanted to first send the PR to make sure I'm on the right path before I add/update tests.

For sure! I was hoping to save you some time. 😜

@Piinks
Copy link
Contributor

Piinks commented Dec 7, 2021

if (pr.base!.ref != 'master' || pr.base!.ref != 'main') {

Does that sound good to you?

SGTM! I think the framework will make that change to main eventually. I hope. :) Thanks!

if (pr.base!.ref != 'master') {
log.fine('This change is not staged to land on master, skipping.');
final String? baseRef = pr.base!.ref;
if (baseRef != 'master' && baseRef != 'main') {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if (baseRef != 'master' && baseRef != 'main') {
if (baseRef != Config.defaultBranch(pr.base!.repo!.slug())) {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice! I'm assuming you'll update the defaultBranch method when flutter/flutter switches to the main branch?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep! Infra is maintaining this API for the default branch instead of hard coding it everywhere

@mdebbar mdebbar requested a review from Piinks December 16, 2021 19:36
Copy link
Contributor Author

@mdebbar mdebbar left a comment

Choose a reason for hiding this comment

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

@Piinks I had to adjust some things in the tests to be able to test for multiple repos. Could you please take a look to make sure I didn't mess things up?

commits(last: 1) {
nodes {
commit {
# (appId: 64368) == flutter-dashboard. We only care about
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Piinks Do we need to change the appId for the engine?

Copy link
Contributor

Choose a reason for hiding this comment

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

I do not think so, it is the same in check_for_waiting_pull_requests_queries.dart, which is used by the merge bot across multiple repositories. @godofredoc would know for sure though.


if (pr.base!.ref != 'master') {
log.fine('This change is not staged to land on master, skipping.');
final String defaultBranch = Config.defaultBranch(slug);
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice!


String _getTriageUrl(int? number) {
return 'https://flutter-gold.skia.org/cl/github/$number';
String _getTriageUrl(RepositorySlug slug, int? number) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably change this to be non nullable. It would be invalid if this got a null PR number.

Future<Map<String, dynamic>?> _queryGraphQL(
GraphQLClient client,
RepositorySlug slug,
int? prNumber,
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here. I do not recall why these would ever be null.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Probably because the PullRequest class has the number property as nullable.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I was thinking that may be so. In that case, we should probably assert somewhere that we have gotten a PR number to work with, otherwise this all breaks.

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

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

LGTM with the null safety nits.
This repo is frozen until 1/4/22, so we should be able to land this then.

@mdebbar
Copy link
Contributor Author

mdebbar commented Jan 4, 2022

@Piinks ping 🙂

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

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

Can you add the assertions that the PR numbers aren't null from the last review?

@mdebbar
Copy link
Contributor Author

mdebbar commented Jan 4, 2022

Can you add the assertions that the PR numbers aren't null from the last review?

Ah, thanks for the reminder. Done.

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

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

Flutter_LGTM

@mdebbar
Copy link
Contributor Author

mdebbar commented Jan 5, 2022

@Piinks I'm unable to merge this PR because only "authorized users" are allowed to. Is this something you can do, or do I have to add my name somewhere?

@Piinks
Copy link
Contributor

Piinks commented Jan 5, 2022

I am not authorized either. @CaseyHillers can you merge this PR?

@mdebbar mdebbar added the waiting for tree to go green Merge PR when tree becomes green via fluttergithubbot label Jan 6, 2022
@fluttergithubbot fluttergithubbot merged commit f7e5d0a into flutter:main Jan 6, 2022
@CaseyHillers
Copy link
Contributor

I am not authorized either. @CaseyHillers can you merge this PR?

As FYI, you'll need to use the waiting for tree to green label. That has the bot handle merges, which will be the defacto way across all repos in a week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting for tree to go green Merge PR when tree becomes green via fluttergithubbot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants