codeql icon indicating copy to clipboard operation
codeql copied to clipboard

Accessing private maven repo using default GitHub configuration

Open futureviperowner opened this issue 1 year ago • 7 comments

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.

image

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?

futureviperowner avatar Jun 04 '24 13:06 futureviperowner

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

smowton avatar Jun 05 '24 14:06 smowton

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

futureviperowner avatar Jun 05 '24 14:06 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.

futureviperowner avatar Jun 05 '24 15:06 futureviperowner

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.

smowton avatar Jun 05 '24 15:06 smowton

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.

futureviperowner avatar Jun 05 '24 15:06 futureviperowner

@futureviperowner do you have an exemplary advanced codeql configuraiton / workflow that exemplifies the auth step against a maven repo. ?

steinheber avatar Sep 12 '24 11:09 steinheber

We share the credentials through environment variables that set the appropriate gradle properties.

name: Release

on:
  push:
    branches: [ main ]

env:
  JAVA_VERSION: 21
  JAVA_DISTRIBUTION: 'temurin'

  ORG_GRADLE_PROJECT_artifactory_user: ${{ secrets.ARTIFACTORY_USER }}
  ORG_GRADLE_PROJECT_artifactory_password: ${{ secrets.ARTIFACTORY_TOKEN }}
  ORG_GRADLE_PROJECT_artifactory_repoKey: libs

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 120

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up JDK
        uses: actions/setup-java@v4
        timeout-minutes: 10
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: ${{ env.JAVA_DISTRIBUTION }}

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v3

      - name: Build
        run: ./gradlew build
        

futureviperowner avatar Sep 18 '24 22:09 futureviperowner