ci: Add vLLM support to integration testing infrastructure

[derekhiggins]

o Introduces vLLM provider support to the record/replay testing framework
o Enabling both recording and replay of vLLM API interactions alongside existing Ollama support.

The changes enable testing of vLLM functionality. vLLM tests focus on
inference capabilities, while Ollama continues to exercise the full API surface
including vision features.

Related: #2888

--
see alternative using qwen here #3545

[derekhiggins]

@ashwinb With this we'll need to run the record tests for 2 providers, but they can't be run in parrallel because

CONFLICT (content): Merge conflict in tests/integration/recordings/index.sqlite

it works if you run them sequentially

@ashwin to avoid conflicts what would you think about removing the index.sqlite file altogether?
From what I can see it is only used to get the path of the recording, and we can instead infer this from the request_hash
there are probably other places this file is going to cause conflicts so possibly its good to remove it anyways

[r3v5]

@ashwinb With this we'll need to run the record tests for 2 providers, but they can't be run in parrallel because

CONFLICT (content): Merge conflict in tests/integration/recordings/index.sqlite

it works if you run them sequentially

@ashwin to avoid conflicts what would you think about removing the index.sqlite file altogether? From what I can see it is only used to get the path of the recording, and we can instead infer this from the request_hash there are probably other places this file is going to cause conflicts so possibly its good to remove it anyways

I also dealt with index.sqlite conflict when re-recorded tests responses for CI.

[derekhiggins]

@ashwinb With this we'll need to run the record tests for 2 providers, but they can't be run in parrallel because

CONFLICT (content): Merge conflict in tests/integration/recordings/index.sqlite

it works if you run them sequentially

@ashwin to avoid conflicts what would you think about removing the index.sqlite file altogether? From what I can see it is only used to get the path of the recording, and we can instead infer this from the request_hash there are probably other places this file is going to cause conflicts so possibly its good to remove it anyways

index.sqlite has been removed here #3254

[mattf]

what about adding these to the skips in the test files directly?

[derekhiggins]

The problem here is because of the model, Our skips in test files are all based on provider
I put the skips here so that it only skips them in CI, anybody running integration test with a more capable model will still be able to use them.

If we can get to the point that this job is running, I'll happy test other models to see if I can get ride of this line alltogether.

[mattf]

yes please, ci w/ a model that passes more tests.

having a gap between what ci test and what developers see in the test suite is going to lead to bugs and confusion.

[derekhiggins]

I've opened an alternative PR that instead use qwen3 #3545
I'll can close which ever one we don't want to go with

[mattf]

what changes did you make in your last force-push?

[derekhiggins]

what changes did you make in your last force-push?

tldr: I removed all of the trivial changes that the ollama record ci job produced

--
I used the ollama record CI jobs to create new recordings for ollama, this resulted in a PR with recordings with mostly trivial changes
this was 72da0de9b01e27f30abe0012875ad09f84b8bb29 101 files changed

I took this commit and removed the trivial changes (these arn't needed),
1a759f5 2 files changed

[derekhiggins]

Closing this i favour of the qwen version (as per discussion in community meeting)
#3545