refactor: Use GraphQL variables instead of string templates

[zharinov]

Changes:

String templates and query string manipulation are too fragile and prevent further refactoring.
It's more convenient to use variables.

Context:

Ref #8386

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

How risky is this refactor? And are we sure there aren't graphql libraries to abstract some of this?

[zharinov]

I've checked query results and pagination, everything works same. I don't know about abstraction, we're mostly just using plain GraphQL in not so many places. The only abstraction is the pagination, but we already solved it (kind of).

[rarkins]

What about the variables used here. Is that your own abstraction or part of graphql?

[zharinov]

They're part of GraphQL specification and transported with the query in the same JSON object

[JamieMagee]

Nice! octokit/graphql.js#2 is also a good summary of why this is a good idea.

[renovate-release]

🎉 This PR is included in version 25.59.0 🎉

The release is available on:

• GitHub release
• 25.59.0

Your semantic-release bot 📦🚀