Accessing private maven repo using default GitHub configuration

[futureviperowner]

Description of the issue

We've been using the advanced configuration option for GitHub for awhile now with no issues. With all of the improvements made to the default configuration option, I wanted to experiment with it to simplify management of our CodeQL configuration. I switched from advanced to default and created a branch that eliminated our CodeQL workflow and configuration file to test it out.

The default CodeQL check triggered and appears to have scanned the code successfully. However, when I view the results under Security | Code scanning | Tools | CodeQL (Default setup) | View configuration, warnings appear that CodeQL was unable to extract dependency information from gradle.

After further investigation this appears to be caused by the fact that our project uses a private maven repo for retrieving dependencies and the CodeQL workflow does not have access to these credentials. Is there a way to fix this or is my only option to stick with the advanced configuration? If the latter, any chance support for this might be added?

[smowton]

In your normal CI process, how do you teach Gradle to access your private repo?

[futureviperowner]

We set some environment variables from GitHub secrets that gradle picks up and uses in our repository configuration.

[futureviperowner]

It occurred to me that calling it "private" might be too vague. It's not private in that it requires a VPN or private network connection. It just requires authentication.

[smowton]

For the time being that does require advanced mode, I'm afraid -- you'd need to expose those variables, or write a .m2/settings.xml file defining a mirror (yes, even for a Gradle-driven analysis). At that point you might as well use an ordinary traced build, unless there are additional difficulties that still make build-mode none valuable?

In the medium term we are intending to provide specific customisations, like exposing environment variables to the action, that can be used while still in default mode.

[futureviperowner]

Thanks for the clarification. I'll keep an eye out for future releases. We'll stick to the advanced configuration that works fine. The attempt to move to default configuration was really just about simplifying (eliminating) workflows and making onboarding a new repo a bit easier.