Abstracted code logic

[Bullrich]

Abstracted GitHub api interaction from the runner method.

This is the first step into isolating the code so it is easier to read.

Second step will isolate the logic

[mutantcornholio]

I feel like this duplicates the purpose of opstooling-integrations. Should we consider reusing it instead?

[Bullrich]

opstooling-integrations

I would be up to use it but would need to check if I can adapt the specific endpoints and combinations that are being called.

Some stuff, like the following, may not be that straightforward to migrate.

octokit.paginate(
      this.octokit.rest.teams.listMembersInOrg,
      { org:pr.base.repo.owner.login, team_slug, per_page: maxGithubApiTeamMembersPerPage },
      (response) => response.data.map(({ login }) => login),
    );

And I would still keep it in a wrapper so it can be tested easier.

But this PR would be a step forward into that direction

[mutantcornholio]

Some stuff, like the following, may not be that straightforward to migrate.

octokit.paginate(
      this.octokit.rest.teams.listMembersInOrg,
      { org:pr.base.repo.owner.login, team_slug, per_page: maxGithubApiTeamMembersPerPage },
      (response) => response.data.map(({ login }) => login),
    );

We have paginated methods there :)

And I would still keep it in a wrapper so it can be tested easier.

One of the major points of creating opstooling-integrations was this exact goal: providing mocks for the endpoints from ground up, ease of use with jest.mock.

But this PR would be a step forward into that direction

Cool