Skip to content

chore(ci): add CodeQL analysis #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jingxiang-z wants to merge 2 commits into from
Closed

chore(ci): add CodeQL analysis #26

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dd5d4f3
chore(ci): add CodeQL analysis
jingxiang-z Jul 30, 2026
89c16b2
Merge branch 'main' into chore/codeql-analysis
jingxiang-z Jul 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions .github/workflows/codeql.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
# SPDX-License-Identifier: Apache-2.0

name: CodeQL

on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: "23 9 * * 1"
workflow_dispatch:

permissions:
actions: read
contents: read
security-events: write

env:
GO_VERSION: "1.26.5"

jobs:
codeql:
name: CodeQL Analysis
runs-on: ubuntu-latest
timeout-minutes: 30

steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0
persist-credentials: false

- name: Set up Go
uses: actions/setup-go@v5
with:
go-version: ${{ env.GO_VERSION }}
check-latest: true
Comment on lines +31 to +40

@coderabbitai coderabbitai Bot Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

sed -n '1,220p' .github/workflows/codeql.yml

Repository: NVIDIA/fleet-intelligence-client

Length of output: 1431

🏁 Script executed:

rg -n "actions/(checkout|setup-go)@|cache:|go build|codeql" .github/workflows .github -S

Repository: NVIDIA/fleet-intelligence-client

Length of output: 3530

🏁 Script executed:

sed -n '1,220p' .github/workflows/codeql.yml && printf '\n---\n' && rg -n "cache:|actions/(checkout|setup-go)@" .github/workflows -S

Repository: NVIDIA/fleet-intelligence-client

Length of output: 2479

🌐 Web query:

actions/checkout latest major Node 24 compatibility actions/setup-go latest major Node 24 compatibility GitHub Actions

💡 Result:

Both actions/checkout and actions/setup-go have been upgraded to support the Node.js 24 runtime [1][2][3]. Key details regarding Node 24 compatibility for these actions are: 1. Compatibility Requirements: Both actions now utilize the Node 24 runtime. To use these latest versions, your GitHub Actions runner must be version v2.327.1 or later [1][2][3]. 2. actions/checkout: Node 24 support was introduced in v5.0.0 [4]. Users are advised to use the latest major version (currently v7) to ensure full compatibility and access to the latest features [1][5]. 3. actions/setup-go: Node 24 support was introduced in the v6 major release [2][3][6]. General GitHub Actions Node 24 Context: As of July 30, 2026, Node 20 is in the process of being deprecated for GitHub Actions runners, with Node 24 becoming the standard runtime [7]. Runners began using Node 24 by default on June 16, 2026 [7]. If you encounter compatibility issues with specific older workflows, you can temporarily allow the use of Node 20 by setting the environment variable ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true, though this is a transitional measure as Node 20 support is being removed [7][8]. Additionally, note that Node 24 is not supported on older environments such as macOS 13.4 and lower, or Linux ARM32 [7][9].

Citations:

Use the current Node 24-compatible action majors and disable Go caching for this job. actions/checkout@v4 and actions/setup-go@v5 are behind the current supported releases, and cache: true can let go build ./... reuse cached objects so CodeQL misses some traced compilations.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/codeql.yml around lines 31 - 40, Update the CodeQL
workflow’s checkout and Go setup steps to use the current Node 24-compatible
action major versions, replacing actions/checkout@v4 and actions/setup-go@v5. In
the setup-go configuration, explicitly disable caching so go build ./...
performs fresh compilations for CodeQL tracing while preserving the existing Go
version settings.

cache: true

- name: Download dependencies
run: go mod download

- name: Initialize CodeQL
uses: github/codeql-action/init@v4
with:
languages: go
build-mode: manual
env:
CODEQL_EXTRACTOR_GO_BUILD_TRACING: "on"

- name: Build with CodeQL
run: go build ./...
Comment on lines +41 to +55

@coderabbitai coderabbitai Bot Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

git ls-files .github/workflows/codeql.yml
echo '---'
cat -n .github/workflows/codeql.yml | sed -n '1,220p'

Repository: NVIDIA/fleet-intelligence-client

Length of output: 1884

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Search for CodeQL / setup-go usage in workflows for context
rg -n "setup-go|codeql-action/init|CODEQL_EXTRACTOR_GO_BUILD_TRACING|go build|go clean -cache|cache: true" .github/workflows -S

Repository: NVIDIA/fleet-intelligence-client

Length of output: 847

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/codeql.yml')
print(p.exists())
PY

Repository: NVIDIA/fleet-intelligence-client

Length of output: 175

🏁 Script executed:

#!/bin/bash
set -euo pipefail

cat -n .github/workflows/codeql.yml | sed -n '1,220p'

Repository: NVIDIA/fleet-intelligence-client

Length of output: 1851

🌐 Web query:

actions/setup-go cache build outputs CodeQL manual mode go build tracing cache skip compiler invocations

💡 Result:

The actions/setup-go action provides built-in support for caching both Go modules and build outputs (the GOCACHE directory) [1][2]. Caching is enabled by default [1][3]. Regarding build tracing and caching in the context of CodeQL: 1. CodeQL Build Tracing: When using CodeQL to create a database for Go, the process involves tracing the build command (e.g., go build) to extract build information [4][5]. In manual mode, you provide the explicit build command that CodeQL should trace [5]. CodeQL uses a build tracer to intercept compiler invocations during this command to collect the necessary data [5][6][7]. 2. Interaction with setup-go Cache: While actions/setup-go can cache the GOCACHE, this cache is managed by the Go toolchain itself based on source changes or dependency files [8][9]. CodeQL's tracing process is primarily concerned with capturing build commands and compiler invocations to generate the database [5]. If you are using setup-go with cache enabled alongside CodeQL, they operate independently: setup-go accelerates your standard Go build/test steps by restoring cached objects, while CodeQL performs its own tracing of the build process to build the database [4][10]. 3. Cache Invalidation and Build Tracing: A key point is that the Go build cache (GOCACHE) is not automatically updated based on source code changes to avoid excessive cache growth [8][9]. If you rely on cached build outputs during a CodeQL manual build, ensure your cache configuration aligns with your project's needs (e.g., by including source files in cache-dependency-path) [8][9]. CodeQL typically requires a clean, full build to correctly trace all files and dependencies for complete analysis [4]. Therefore, relying on heavily cached, incremental build outputs in a CodeQL tracing environment might sometimes lead to incomplete data capture if the tracer relies on seeing the full build process [5][6]. Users often perform a clean build for CodeQL analysis to ensure all dependencies and source files are correctly traced [4][10].

Citations:

🌐 Web query:

GitHub Actions setup-go cache go build outputs compiler cache CodeQL manual mode traced build incomplete coverage

💡 Result:

For GitHub Actions, the setup-go action provides built-in caching for both Go modules and build outputs (the GOCACHE directory), enabled by default [1][2]. If you require finer control, such as cache key separation for different build jobs or specific flags, you can disable the built-in cache (cache: false) and manually configure actions/cache [2][3]. Regarding CodeQL and traced builds, CodeQL requires a complete build to observe compiler activity for accurate data flow analysis [4]. When using build-mode: manual, CodeQL analyzes exactly what your specified build commands produce [5][6]. "Incomplete coverage" or errors in CodeQL results often arise from the following: 1. Tracing Issues: CodeQL must "see" the compiler invocations [4]. If your build runs in a separate container, uses a distributed build system/daemon, or uses a compiler version CodeQL does not recognize, extraction may fail [4]. 2. Build Incompleteness: If components of your project are cached (e.g., incremental builds via Gradle/Bazel/Go build cache) and do not trigger a full recompile during the CodeQL step, CodeQL may miss these portions because no new compiler invocations are observed [4]. Ensure that the build commands executed during the CodeQL init and analyze steps perform a full, non-cached build or explicitly clear relevant build caches [4]. 3. Manual Build Configuration: Ensure that any required environment variables or dependencies are available during the manual build step, as CodeQL's tracer only captures commands executed within the run steps of the CodeQL workflow [5][4]. If you suspect incomplete coverage, verify that the workflow does not rely on pre-compiled artifacts or incremental build optimizations that bypass the compiler during the CodeQL analysis phase [4].

Citations:

🌐 Web query:

site:github.com/actions/setup-go README cache GOCACHE default enabled

💡 Result:

The environment variable GOCACHE is used by the Go toolchain to specify the location of the build cache, and it is enabled by default in all standard Go installations. You can verify its active location at any time by running the command go env GOCACHE [1][2]. If your query concerns the caching behavior within the GitHub Actions actions/setup-go workflow, please note the following: 1. Go's native build cache (GOCACHE) and module cache (GOMODCACHE) are managed by the Go toolchain itself, not by the action. The action merely provides a mechanism to persist these directories between workflow runs to improve build speeds [1][3]. 2. In actions/setup-go (starting from version 4), caching is enabled by default [4][5]. This means the action will automatically attempt to save and restore the paths returned by go env GOCACHE and go env GOMODCACHE [1][3]. 3. To disable this default caching behavior in your GitHub Actions workflow, you must explicitly set the cache input to false [6][7]: - uses: actions/setup-go@v6 with: go-version: '1.23' cache: false

Citations:

🌐 Web query:

site:docs.github.com CodeQL manual build tracing compiler invocations complete build source code seen during build

💡 Result:

CodeQL captures source code for analysis by instrumenting the build process to intercept and observe compiler invocations [1][2]. When using a manual build approach, CodeQL relies on these observations to understand data flow and create the database [2][3]. Core Mechanisms for Tracing Builds 1. Direct Tracing: You can wrap your build command directly with the CodeQL tracer. This is typically done using the codeql database trace-command command [4][5][6]. This command runs your specified build process under an instrumentation environment that automatically detects compiler invocations [6][3]. 2. Indirect Build Tracing: If you cannot wrap your build command, you can use indirect tracing [5]. This involves running codeql database init with the --begin-tracing flag, which generates files (such as start-tracing.sh or start-tracing.bat) containing environment variables [5]. These variables enable CodeQL to trace build processes across multiple CI steps when they are set in your environment [5]. The tracing ends after you run codeql database finalize [5]. Common Causes for "No Source Code Seen" Errors If CodeQL reports that no source code was seen during the build, it is often due to [2]: * Compilation outside the init and analyze steps: The build must occur while the CodeQL tracer is active (i.e., between init and finalize) [2][5]. * Build systems with caching: If your build system (e.g., Gradle or Bazel) uses cached components, the compiler may not be invoked for all source files, preventing CodeQL from observing them [2]. * Compilation not detected: The build may run in a separate container, use a daemon process that hides invocations from the tracer, or use a compiler that CodeQL does not recognize [2]. * Incomplete builds: CodeQL requires a complete build to observe the necessary data flows [2]. For manual builds, ensure your workflow explicitly sets build-mode: manual and that your build commands are executed within the scope of the active CodeQL tracing environment [7][8]. If necessary, you can use advanced tracer configuration files (--extra-tracing-config) to help CodeQL identify specific compiler processes [4][3].

Citations:

Clear the Go build cache before the traced CodeQL build. actions/setup-go restores GOCACHE, and CodeQL manual mode only records compiler invocations during go build; if unchanged packages come from cache, they won’t be traced and coverage can be incomplete.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/codeql.yml around lines 41 - 55, Clear the restored Go
build cache after dependency download and before the CodeQL-traced build, using
the workflow steps around “Download dependencies” and “Build with CodeQL”; keep
the manual CodeQL initialization and build unchanged so all packages are
recompiled and traced.


- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v4
with:
category: "/language:go"
Loading