Three core apps have never been scanned by CodeQL
launchpad, portaliq and openbuild have no code scanning at all. Not
green — absent.
Measured 2026-08-17, with a positive control so the probe is known to be able to
say "yes":
| repo |
code-scanning/default-setup |
codeql workflow file |
analyses ever |
| launchpad |
not-configured |
none |
0 (404 "no analysis found") |
| portaliq |
not-configured |
none |
0 (404 "no analysis found") |
| openbuild |
not-configured |
none |
0 (404 "no analysis found") |
| openconnector (control) |
configured |
— |
many |
The other 15 core apps are all configured and carry between 7 and 16 open
alerts each.
Why this is worth an issue
A repo with no analysis produces no CodeQL check-run at all. On any
dashboard that lists red checks, these three look exactly like the repos that
passed. This is the "a workflow that never started is absent, not failing"
shape: there is no red to notice, no skip to question, and no run to inspect.
The fleet's other 15 repos each carry 7–16 open
actions/missing-workflow-permissions alerts. There is no reason to believe
these three are cleaner; they are simply unmeasured. Whatever they would have
found has been invisible for as long as the repos have existed.
⚠️ Note launchpad and portaliq also differ on default branch (main vs
development), and the code-scanning/alerts API defaults to the default
branch — so once scanning is enabled, any fleet sweep must pass
ref=refs/heads/development explicitly or it will measure the wrong branch.
Suggested action
Enable CodeQL default setup on all three (or add the fleet-standard workflow),
then re-run whatever sweep last reported the fleet "clean" — its previous answer
for these three was not a pass.
Provenance
Found while clearing the CodeQL reds on openconnector, softwarecatalog and
larpingapp (ConductionNL/openconnector#1280, ConductionNL/softwarecatalog#538,
ConductionNL/larpingapp#339). Not fixed here because enabling scanning on three
repos is a change to their CI posture, not a cleanup.
Three core apps have never been scanned by CodeQL
launchpad,portaliqandopenbuildhave no code scanning at all. Notgreen — absent.
Measured 2026-08-17, with a positive control so the probe is known to be able to
say "yes":
code-scanning/default-setupnot-configurednot-configurednot-configuredconfiguredThe other 15 core apps are all
configuredand carry between 7 and 16 openalerts each.
Why this is worth an issue
A repo with no analysis produces no
CodeQLcheck-run at all. On anydashboard that lists red checks, these three look exactly like the repos that
passed. This is the "a workflow that never started is absent, not failing"
shape: there is no red to notice, no skip to question, and no run to inspect.
The fleet's other 15 repos each carry 7–16 open
actions/missing-workflow-permissionsalerts. There is no reason to believethese three are cleaner; they are simply unmeasured. Whatever they would have
found has been invisible for as long as the repos have existed.
launchpadandportaliqalso differ on default branch (mainvsdevelopment), and thecode-scanning/alertsAPI defaults to the defaultbranch — so once scanning is enabled, any fleet sweep must pass
ref=refs/heads/developmentexplicitly or it will measure the wrong branch.Suggested action
Enable CodeQL default setup on all three (or add the fleet-standard workflow),
then re-run whatever sweep last reported the fleet "clean" — its previous answer
for these three was not a pass.
Provenance
Found while clearing the CodeQL reds on openconnector, softwarecatalog and
larpingapp (ConductionNL/openconnector#1280, ConductionNL/softwarecatalog#538,
ConductionNL/larpingapp#339). Not fixed here because enabling scanning on three
repos is a change to their CI posture, not a cleanup.