| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
What do you think about making this a catch-all debug option, potentially including other changes like increasing the verbosity of CLI commands? |
Sorry, something went wrong.
That sounds like a sensible idea, yes. For this PR let's stick to just uploading artifacts, but we can name it debug to give us room to have that flag do more things in future. Follow-up question - if it's a general debugging flag should it go in the init step instead? I think that would make sense in case we want to debug something from before the analyze step. |
Sorry, something went wrong.
| logger | ||
| ); | ||
|
|
||
| if (config.debugMode) { |
There was a problem hiding this comment.
Is there ever a danger of running with debugMode === true on the runner? Presumably, if so, the runner would fail on the upload stage, but it would be nice if we could detect this and fail faster.
Sorry, something went wrong.
There was a problem hiding this comment.
Note, this will be caught (if it is indeed a problem) by updating the unguarded-action-lib.ql query.
Sorry, something went wrong.
There was a problem hiding this comment.
It should never be possible to be in debug mode when using the runner. In particular, note that the call to initConfig in runner.ts has gained a hard-coded value of false for the parameter specifying whether we are in debug mode.
Sorry, something went wrong.
| import * as fs from "fs"; | ||
| import * as path from "path"; | ||
|
|
||
| import * as artifact from "@actions/artifact"; |
There was a problem hiding this comment.
I think the unguarded-action-lib.ql query should be updated to include calls to @actions/artifact.
Sorry, something went wrong.
There was a problem hiding this comment.
Unless I'm misunderstanding that query, it will already be including these calls as they match
codeql-action/queries/unguarded-action-lib.ql
Lines 17 to 20 in 4293754
Sorry, something went wrong.
There was a problem hiding this comment.
Yep...sorry...you're right here.
Sorry, something went wrong.
| async function uploadDebugArtifact(toUpload: string[], rootDir: string) { | ||
| await artifact.create().uploadArtifact( | ||
| DEBUG_ARTIFACT_NAME, | ||
| toUpload.map((file) => path.normalize(file)), |
There was a problem hiding this comment.
Hmmm...artifacting lots of little files (eg- a database) can take a really long time. It looks like you're doing this in several places. Much better to zip things up first and then upload.
Sorry, something went wrong.
There was a problem hiding this comment.
Take a look and see if this really is a problem in the action, but I've encountered it before in semmle-code.
Sorry, something went wrong.
There was a problem hiding this comment.
Actually, you may already be zipping things, so maybe this is a noop.
Sorry, something went wrong.
There was a problem hiding this comment.
This is indeed a no-op, I think. The only place this a concern is databases since, as you say, they contain lots of little files. These are being zipped up using codeql database bundle. The SARIF and some of the logs (those that exist outside of a database) are being uploaded unzipped, but that is okay because they are only a couple of files.
Sorry, something went wrong.
|
Updating the query can happen in a different PR. |
Sorry, something went wrong.
There was a problem hiding this comment.
Nice. All my comments turned into noops. Thanks for explaining. The code looks fine to me. Just need to address merge conflicts and 🚢 .
Sorry, something went wrong.
|
Thanks! Have squashed and rebased to address the merge conflicts. |
Sorry, something went wrong.
|
I think this needs a changelog entry. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR adds a new option debug-artifacts to the analyze step which will result in the following files being uploaded as artifacts in order to aid debugging: