LLM assistant

Added in 1.1.0. Not available in 1.0.0 — what changes on upgrade.

The assistant analyses failed CI jobs from their log and the changes in a pull request. The model is chosen by the instance administrator: a node inside your own network or a cloud provider with an OpenAI-compatible API. A Pro edition capability.

Configuration: Administration → AI assistant.

The air-gap boundary

This is the first thing to know when deploying into an isolated network.

An unconfigured or disabled assistant makes no outgoing request at all. The refusal is issued before a request to the model is even assembled: the log content goes nowhere. An installation without a configured provider behaves exactly as if the assistant were not in the product.

A configured assistant talks to exactly one address - the one the administrator set. Automatic 3xx redirects are forbidden: another server’s response cannot carry the request content off to a different host.

Provider	Scheme	Address	Where the content goes
Own node	http or https	any, including private ranges	inside your network
Cloud	https only	must resolve to a public address (SSRF protection)	to the external provider

Private ranges are allowed only for your own node: http://ollama:11434/v1 on a docker network resolves to a private address, and a blanket ban would close exactly the case an isolated network is built for. http is forbidden for a cloud provider: source code would leave for the other side in plain text.

Where requests go is visible in the interface: the provider host is shown in the settings and on the analysis button, and for a cloud provider there is a warning that content leaves your network.

CI secrets do not reach the log: masked variable values are cut out as the log is written, that is, before the log could ever be handed to a model.

Providers

Any server with a POST {base_url}/chat/completions API will do:

• Ollama - http://node:11434/v1, a model such as qwen2.5-coder:7b;
• vLLM, llama.cpp server, LM Studio - their own address, the model by name;
• cloud providers with the same API - https://…/v1 and an access key.

The access key is stored encrypted (AES-256-GCM) and is never returned in any API response: the interface only shows whether one is set. An empty key field when editing the settings means “keep the previous one”.

The “Test connection” button asks the provider for its model list, checks the model name against it, and then makes a trial exchange - one word and a single allowed response token. The trial exchange is needed because some providers expose the model list without a key: without it the check would answer “provider available” where the assistant then fails with 401. The check can be run before saving the settings.

How long to wait for the model. “Response timeout” - from 1 to 600 seconds, 180 by default. Three minutes, not one: a reasoning model thinks before answering, and a local one on a CPU is slow. If the model did not make it, the participant sees exactly that - “the model did not answer within N seconds” - rather than “provider unavailable”.

Analysis of a failed CI job

On the pipeline page a failed job gets an “Analyse failure” button. The assistant receives the job context (repository, branch, name, stage, exit code, image) and the tail of the log, and returns the cause, an explanation and what to do.

• The answer is marked as machine-generated - the reader sees that the text was not written by a human, and by which model.
• The log is handed over as a tail: the cause of a failure is almost always at the end, while the beginning is taken up by installing dependencies. If the log did not fit in full, both the model and the reader are told so.
• Analysis is available to those with write access to the repository. Read access is deliberately not enough: a request spends the repository owner’s monthly limit, and on a public repository a stranger could exhaust someone else’s limit in a single loop of requests.
• A successful job is not sent for analysis.

Analysis of pull request changes

A participant with write access presses “Analyse changes”. The model receives the title, description, branches and the text of the changes, and the answer is published as an ordinary comment marked “Generated by a model”.

• The comment is ordinary on purpose: otherwise the analysis would land neither in the discussion feed, nor in threads, nor in the unresolved counter. The marker is set by the server; a client cannot declare its own comment machine-generated.
• The author of the comment is whoever requested the analysis: it is visible at whose request it appeared, while edit and delete rights stay as usual.
• Files are handed to the model in full and in order, as long as the budget lasts: half a patch is invented context from which the model draws conclusions about code it never saw. Binary files and those that did not fit are listed separately.
• A request with no changes is not sent for analysis.

Spend accounting and limits

Spend is charged to the repository owner - the user or the group, the same side storage quotas are counted against. Not to whoever pressed the button: analysing a build of a team repository is the team’s spend.

The accounting window is a calendar month. The default is set in the assistant settings, an owner override - in the spend table. Zero means “no limit”, and an override outranks the default: zero for an owner lifts the instance limit rather than forbidding requests.

The limit is checked before the request to the model: nobody knows in advance how many tokens the next request will take, so the rule reads “a new request cannot be started” rather than “cut off mid-sentence”. Such a limit is meant as a budget, not as a barrier: set it from the monthly norm. If the provider does not report spend, it is estimated from the length of the texts.

On top of the monthly limit there is a rate limit - 10 requests per minute per client, shared between failure analysis, change analysis and the provider connection test. Exceeding it gives 429 with a Retry-After header.

What is visible in a refusal. The provider’s detailed error goes only to the administrator - into the connection test and the server log. Whoever pressed “Analyse failure” gets the refusal code without details: providers return the prefix of the presented key in their error messages, and the text of a connection error contains the model node’s address.