Skip to content

fix(ci): set LLM_PROVIDER=mock to prevent OpenAI init at import time#495

Open
steadhac wants to merge 1 commit into
GenAI-Security-Project:mainfrom
steadhac:steadhac/fix/ci-llm-provider
Open

fix(ci): set LLM_PROVIDER=mock to prevent OpenAI init at import time#495
steadhac wants to merge 1 commit into
GenAI-Security-Project:mainfrom
steadhac:steadhac/fix/ci-llm-provider

Conversation

@steadhac
Copy link
Copy Markdown
Contributor

@steadhac steadhac commented May 9, 2026

No description provided.

@joshlochner
Copy link
Copy Markdown
Contributor

Could we use the Ollama build in #497 as a way to have an instance of LLM_PROVIDER instantiated that doesn't rely on mock

@stealthwhizz
Copy link
Copy Markdown
Contributor

@joshlochner Using Ollama in CI would require installing the binary, pulling a model, and starting a server on every run. That adds significant time and disk usage, and LLM responses are non-deterministic so unit tests would be flaky. LLM_PROVIDER=mock is the right fix for CI - it's instant, deterministic, and tests the code logic rather than model behaviour.

Ollama makes more sense for local dev or E2E tests.

@steadhac
Copy link
Copy Markdown
Contributor Author

@joshlochner Thanks for the suggestion! The reason we use the mock client in CI rather than Ollama/Llama is that it keeps the test environment self-contained — no running server, no model weights, no GPU dependency. A live Ollama process isn't available in the CI runner, so tests would fail with a connection error the same way they currently fail with the missing OpenAI key.

The mock client is also intentional for unit tests specifically: it returns deterministic responses, runs instantly, and tests the code around the LLM rather than the LLM itself. If you want to validate actual model behavior, that belongs in a separate integration test suite that runs on demand, not on every PR.

Happy to discuss adding an optional Ollama integration test job that developers can trigger manually — but for the default CI pipeline, mock is the right choice.

Thanks, @stealthwhizz, for answering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants