Skip to content

Conversation

@chrisgavin
Copy link
Contributor

Currently our requests to the GitHub API are pretty inconsistent. In a few places we use an Octokit, but we construct them at the point of use potentially leading to them being initialized inconsistently. We also sometimes just use an HTTP client.

Perhaps most importantly, none of these methods actually respect the GITHUB_API_URL environment variable that tells you where to find the GitHub API.

Because of this I've replaced these custom Octokits and the HTTP client with a single Octokit to ensure that all requests are made consistently and to the correct host.

Merge / deployment checklist

  • Run test builds as necessary. Can be on this repository or elsewhere as needed in order to test the change - please include links to tests in other repos!
    • CodeQL using init/analyze actions
    • 3rd party tool using upload action
  • Confirm this change is backwards compatible with existing workflows.
  • Confirm the readme has been updated if necessary.

baseUrl: githubAPIURL,
userAgent: "CodeQL Action",
log: consoleLogLevel({ level: "debug" })
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Eventually could we make a class that wraps octokit.Octokit and supplies higher level functions a-la octokit?

For example

octokit.repos.codeScanning.uploadAnalysis({
  owner,
  repo,
  analysis
});

Copy link
Contributor

Choose a reason for hiding this comment

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

Or hopefully once we're fully out of beta then we can have our methods in the proper Octokit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep. Octokit actually does have methods to add custom endpoints which I did experiment with, but it unfortunately adds typing-related complications. Ideally these methods are eventually part of the real API.

Copy link
Contributor

@robertbrignull robertbrignull left a comment

Choose a reason for hiding this comment

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

Couple of points, but generally this looks like a big improvement in standardisation to me.

import * as octokit from "@octokit/rest";
import consoleLogLevel from "console-log-level";

const githubAPIURL = process.env["GITHUB_API_URL"] || "https://api.github.com";
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you have any public documentation for this env var? It doesn't seem to exist on dotcom actions, but maybe it does for enterprise actions. Otherwise I was going to suggest always requiring it to exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, in a test job I did it existed on both. e.g. See https://github.com/chrisgavin/test-actions/runs/803393860?check_suite_focus=true.

I'm happy to require it exists, though I experienced some very strange issues when trying to use util.getRequiredEnvParam(...) here. Specifically it seems like the Action fails at runtime with the error getRequiredEnvParam is not a function. I wondered if it could be due to an import loop or something but I never managed to figure it out.

import consoleLogLevel from "console-log-level";

const githubAPIURL = process.env["GITHUB_API_URL"] || "https://api.github.com";
export const client = new octokit.Octokit({
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this makes sense as a const, however I am worried that https://github.com/github/codeql-action/blob/main/queries/undeclared-action-input.ql won't understand this. This shouldn't be impossible to fix, but maybe also not trivial.

For now every action does declare the token input, but it would be nice to have it be checked. I am happy for us to note this and fix it in a later pull request.

// On any other status code that's not 5xx mark the upload as failed
if (!statusCode || statusCode < 500 || statusCode >= 600) {
core.setFailed('Upload failed (' + requestID + '): (' + statusCode + ') ' + await res.readBody());
core.setFailed('Upload failed (' + requestID + '): (' + statusCode + ') ' + response.data);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think response.data is an object, so you might want to JSON.stringify here. Also applies to other times that the data is appended to a string.

@robertbrignull
Copy link
Contributor

I think a couple of places that making using custom requests could use built-in octokit methods, but making that change at a later date sounds good to me.

@chrisgavin
Copy link
Contributor Author

I think a couple of places that making using custom requests could use built-in octokit methods, but making that change at a later date sounds good to me.

100%. I was actually pretty surprised we didn't already use built-in methods for things like getting the languages of a repository.

Copy link
Contributor

@robertbrignull robertbrignull left a comment

Choose a reason for hiding this comment

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

LGTM now

@chrisgavin chrisgavin merged commit 1754806 into main Jun 26, 2020
@chrisgavin chrisgavin deleted the octokit branch June 26, 2020 10:03
sampart added a commit that referenced this pull request Jun 26, 2020
@github-actions github-actions bot mentioned this pull request Jun 29, 2020
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.

4 participants