Passing all files as command-line arguments via the spread operator could hit command-line length limits in repositories with very large numbers of files (e.g., tens of thousands). Consider usinggit check-attr --stdin instead, which reads file paths from stdin and avoids this limitation. This would involve piping the file list to git rather than passing it as arguments.

The stub created in this test is not restored after the test completes. This could cause test pollution if other tests rely onrunGitCommand behavior. Consider wrapping the test in a try-finally block or usingt.teardown() to restore the stub, similar to how it's done in other tests in this file (e.g., lines 393-394).

Splitting onos.EOL will include an empty string at the end of the array if the git output ends with a newline (which is typical). This empty string will then be passed togit check-attr ingetGeneratedFiles. Consider filtering out empty strings:return stdout.split(os.EOL).filter((line) => line.length > 0);

Splitting onos.EOL will include an empty string at the end of the array if the git output ends with a newline (which is typical). The regex won't match empty strings, but it's cleaner to filter them out explicitly:for (const result of stdout.split(os.EOL).filter((line) => line.length > 0)). This pattern is used elsewhere in the codebase (e.g., line 284 checksif (line) before processing).

Missing JSDoc documentation. Consider adding a comment explaining what this function does, its parameters, and return value. For example:/**\n * Returns a list of files marked as generated via the linguist-generated attribute in .gitattributes.\n * @param workingDirectory The directory to check for generated files.\n * @returns An array of file paths (relative to the working directory) that are marked as generated.\n */

The stubrunGitCommandStub is not restored after the test completes. Add a try-finally block or uset.teardown() to ensure the stub is restored, similar to how it's done in other tests in this file (e.g., lines 393-394).

The logic can be simplified. The|| false is needed to convertundefined from optional chaining tofalse, but the outer parentheses are unnecessary. Consider:return isDynamicWorkflow() && (process.env["CODEQL_ACTION_ANALYSIS_KEY"]?.startsWith("dynamic/copilot-pull-request-reviewer") ?? false); This is clearer and uses the nullish coalescing operator which is more explicit about handlingundefined.

This test directly modifiesprocess.env without proper cleanup, which could cause test pollution. Consider usingwithMockedEnv (defined at line 30) to ensure environment variables are restored after the test, similar to how it's done in other tests in this file (e.g., lines 206-251).

This test directly modifiesprocess.env without proper cleanup, which could cause test pollution. Consider usingwithMockedEnv (defined at line 30) to ensure environment variables are restored after the test, similar to how it's done in other tests in this file (e.g., lines 206-251).

What about introducing an environment variable we set in CCR, rather than relying on the analysis key?

As discussed elsewhere, that is sort of what we are doing here already (and we decide on whether are in CCR in other places in the same way currently).

A better solution would be to add a new analysis kind (or similar) for CCR, but that would be more work and currently the same ascode-quality in essentially everything but name.

I'd suggest we should stick with this for the moment (since we also use the same approach elsewhere) and look at improving it longer-term.

This could potentially be a very large number of files, too many to pass on the command line.

If we're mainly interested in CCR, could we filter down to just the diff here?

Alternatively, we could parse globs from the.gitattributes file rather than finding all files that match. That would be more likely to contain one entry for a large directory rather than potentially hundreds.

Or we could add a limit on the number of files on which we'll runcheck-attr.

This could potentially be a very large number of files, too many to pass on the command line.

True. The files could be passed in viastdin as well I think, which might be a more robust solution.

If we're mainly interested in CCR, could we filter down to just the diff here?

Potentially. We should first look at whether there is actually enough of a performance hit for large repos for this to make sense though.

Alternatively, we could parse globs from the .gitattributes file rather than finding all files that match. That would be more likely to contain one entry for a large directory rather than potentially hundreds.

I considered this, but I'd like to avoid it if we can get the information fromgit itself so we don't have to try and duplicate what it does.

Have you measured how long this operation takes overall on a large mono-repo?

I believe it should be relatively quick, since Git caches this information IIRC. That said, I haven't explicitly tested it on a large repo, but I can do that.

I'd advise rolling this out behind a feature flag first, even in CCR.

This was actually an&&, but I changed it for testing purposes 😅