Repository navigation
[Reliability] Remove CodeQL Python legacy-version autodetection diagnostics #2104
Description
Finding
A fresh protected-central CodeQL dispatch on ContextualWisdomLab/.github@cb0872c9a20d5584703dffacca65c096fc034c6c for accounting-information-platform#59@607b72de0dff276c8ea04c04041c6820615663a3 emitted avoidable Python-version autodetection diagnostics during github/codeql-action@cdf488f595d80d6e07e03d4674febd5ab45fa938 / CodeQL CLI 2.27.0 initialization:
/bin/sh: 1: python2: not foundWill try to guess Python version, as it was not specified in lgtm.ymlWanted to run Python 2, but it is not available. Using Python 3 instead- the same extractor then reports
Python version 3.12.3and completes analysis successfully.
This is not a vulnerability finding and did not make the Medium+ SARIF gate fail. It is nevertheless a reliability/operability defect for the central reusable CodeQL path: a current Python-only scan should not rely on a legacy Python-2 probe or ambiguous version guessing when the intended interpreter is known. Log filtering or ignoring the diagnostic is not acceptance.
The separate systemd Standard output type syslog is obsolete warning remains owned by #2103. Cross-repository status publication / Actions wake / settlement-ordering failures remain owned by the existing CodeQL repair lineage; this issue must not widen into those problems.
Required investigation
Identify which supported CodeQL Action / extractor configuration owns Python interpreter selection for build-mode: none in the current pinned action/bundle. Determine whether the legacy python2 probe is caused by missing explicit configuration, an upstream CodeQL 2.27.0 extractor behavior, or another central wrapper assumption. Prefer a supported explicit configuration or upstream-fixed immutable dependency over shell aliases, fake python2, stderr suppression, or runner mutation.
RED / GREEN acceptance
RED must reproduce the diagnostic from the central reusable dispatch path on an exact test head without weakening CodeQL queries, SARIF gating, source identity checks, or action pinning.
GREEN must prove on a fresh exact-head Python dispatch that:
- the intended supported Python interpreter/version is selected deterministically;
- no
python2: not found, legacy-version guessing, or contradictory Python-version diagnostic is emitted; - CodeQL analysis, Medium+ SARIF gating, SARIF artifact preservation, and exact source binding remain intact;
- any dependency update is immutable-pinned and reconciled with the repository's action-pin annotation/contract owners; and
- the fix is reusable by consumers rather than copied into product repositories.
If current CodeQL provides no supported configuration that removes the probe, record upstream evidence and the minimum immutable upgrade that does, then verify it in the central owner before consumer adoption.
Owner / writer boundary
Before changing workflow or contract-test paths, re-read live .github PRs for overlapping CodeQL/action-pin/dependency writers. Reconcile by ordinary non-force history onto the canonical current-base owner; do not open a competing source writer, force-push, weaken a gate, or manufacture an empty wake commit merely to exercise this issue.
Activity
seonghobae commentedon Sep 13, 2026
Root cause, verified in the extractor source shipped with CodeQL CLI 2.27.0 (
github/codeqltagcodeql-cli/v2.27.0,python/extractor/buildtools/):index.py:main()→discover.get_version()→version.best_version(root, default). IfLGTM_PYTHON_SETUP_VERSIONis not in the environment it printsWill try to guess Python version, as it was not specified in \lgtm.yml`and runstrove_version() or travis_version() or machine_version().machine_version()callsexecutable(2), which is whereWanted to run Python 2, but it is not available. Using Python 3 insteadcomes from (version.py:57-64). WithLGTM_PYTHON_SETUP_VERSION=3set,best_version()returns3immediately (version.py:210-216`) and neither of those two lines is emitted./bin/sh: 1: python2: not found, is the shell's stderr fromset_available_versions()(version.py:42-55), which probes bothpython3 -c passandpython2 -c passunconditionally the first time anyexecutable(...)call happens — andindex.py:site_flag(3)(index.py:379) makes such a call on every run regardless of the env var. So that one line cannot be removed from the consumer side; it needs an upstream change (probe only the requested major version, or honourCODEQL_EXTRACTOR_PYTHON_OPTION_PYTHON_EXECUTABLE_NAME/LGTM_PYTHON_SETUP_VERSIONbefore probing).Consumer-side repair (2 of 3 diagnostics), one env line on the CodeQL init/analyze steps of
codeql-scan-dispatch.yml(Initialize CodeQL/Perform CodeQL Analysis, currently at ~L411-425 onmain@fb17ef556):Guard it with a contract test asserting the env is present on both steps (and only affects the
pythonmatrix leg semantically — it is inert foractions). Not opened as a competing PR:codeql-scan-dispatch.ymlis touched by 81 open PRs and #2106 / #2040 / #2051 all carry hunks around the init step; whichever of those lands first should bundle this line, or it goes in immediately after they merge. Upstream ask for the remaining line: file againstgithub/codeql(python/extractor/buildtools/version.py::set_available_versions) — not filed yet.Internal next review: 2026-09-20 (after the CodeQL dispatch stack settles). Not suppression, not resolved.