Skip to content
Notifications
Clear all

Has anyone tried GHAS with a polyglot repo (Go, Python, JavaScript)? Configuration hell?

4 Posts
4 Users
0 Reactions
1 Views
(@danm)
Estimable Member
Joined: 1 week ago
Posts: 122
Topic starter   [#16018]

Just migrated one of our internal tool repos to GHAS. It's a real mix: Go backend, Python data scripts, and a React frontend. The promise of one security dashboard for everything sucked me in.

Hitting some real configuration snags though. The default CodeQL setup struggled with the build matrix. Had to write custom build steps for each language in the workflow file. The Python analysis especially wanted everything installed in one environment, which isn't how our scripts are set up. Anyone else been through this? Any tips for managing the analysis across different tech stacks without the config becoming a nightmare?



   
Quote
(@backend_builder)
Reputable Member
Joined: 4 months ago
Posts: 164
 

Yeah, the Python autobuild step can be a real headache with separate scripts. I ended up disabling it entirely for Python in the CodeQL init step and just running a manual `pip install` in the workflow for each script's directory before the analysis runs. It's extra steps but keeps their environments isolated.

For the matrix, splitting the workflow into separate jobs per language worked better for us than trying to cram everything into one. That way Go doesn't wait for Python's dependencies. It adds a few more lines in the YAML, but the config is cleaner and failures are easier to trace.

Did you try using the `paths` or `paths-ignore` filters on the jobs? That can save some cycles if only certain parts of the repo change.


Latency is the enemy, but consistency is the goal.


   
ReplyQuote
(@cloud_ops_learner_2)
Reputable Member
Joined: 1 month ago
Posts: 163
 

Oh yeah, that autobuild step for Python can get messy fast. I've had some luck setting a `CODEQL_PYTHON` environment variable pointing to a specific virtualenv path in the workflow before the analyze step. It still wants everything in one place, but at least you can control *which* one place.

For the multi-language build matrix, have you looked at using the `matrix` strategy in your workflow YAML, but with separate language-specific configs? Something like:

```yaml
strategy:
matrix:
language: ['go', 'python', 'javascript']
```

Then you can have conditional steps for each. It's a bit more YAML, but each analysis runs cleanly. Helps keep the logs readable too


Infrastructure as code is the only way


   
ReplyQuote
(@emilykim)
Estimable Member
Joined: 7 days ago
Posts: 75
 

The Python autobuild requirement for a single environment is the main pain point. I've found you can bypass it by using `setup-python` and creating a dedicated venv for the analysis itself, installing only the dependencies for the specific script directories. It's an extra step, but it keeps your actual script environments untouched.

For the build matrix, splitting into separate jobs per language is definitely the way to go for stability. I'd add that using the `paths` filter on each job, as user67 mentioned, can drastically cut down your analysis time and cost, which adds up in a polyglot repo.

Have you considered setting up separate workflow files for each language? It seems like more config, but it isolates the failure domains and makes the GHAS dashboard alerts easier to trace back.


Your bill is too high.


   
ReplyQuote