Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mislav
Copy link
Contributor

@mislav mislav commented May 12, 2020

Command tested:

gh pr create -R github/github -t 'title' -b 'body' -a hubot -r github/<team> -l bug

Results:

  • before: 18.420s spent in metadata resolve
  • after: 0.411s spent in resolve

This is achieved by avoiding preloading all org users and teams (as it would if assignees or reviewers were requested in interactive mode) and manually assembling a query that resolves an assortment of GraphQL nodes to IDs in bulk.

Followup to #787

@mislav mislav requested review from probablycorey and vilmibm May 12, 2020 15:03
Copy link
Contributor

@vilmibm vilmibm left a comment

Choose a reason for hiding this comment

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

nice work!

I am into this and don't have any concerns with the code or tests.

I noticed though that we need to sidestep the githubv4 library we decided to adopt to pull off this kind of thing. I'm assuming we'll have enough "simple" queries for us to want to keep using the githubv4 tool in the longer term despite having exceptions like this; would you agree?

This was due to a typo. Fixes #913
@mislav
Copy link
Contributor Author

mislav commented May 13, 2020

I noticed though that we need to sidestep the githubv4 library we decided to adopt to pull off this kind of thing. I'm assuming we'll have enough "simple" queries for us to want to keep using the githubv4 tool in the longer term despite having exceptions like this

This is a great point to bring up! Yes, I share your feelings. I couldn't figure out a way to pull off this kind of bulk query with githubv4, especially because of the variable inputs/outputs that are hard to describe with static structs. Go's reflect interface offers us to dynamically create structs at runtime and this could theoretically work with githubv4, but that didn't feel any more cleaner, so I opted to drop down to our old GraphQL interface for this. I still hope that we can figure out how to move all the queries to a single adapter and in the meantime we should keep old-style queries to a minimum.

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