Concierge

Guided onboarding and an AI assistant trained on your Jenkins environment, securely scoped to each user's current permissions.

The welcome page as alice, a developer on the payments team, sees it. Every number, job and tour on it is computed from what she can read, so the platform team's jobs are simply not there.

Played here at three times speed. Watch the full demo: two minutes with English captions, covering the welcome page, a guided tour, a learning path, and the assistant answering a question and proposing a build. To try the same thing yourself, see Trying it locally.

Joining a team means joining its Jenkins: hundreds of jobs, folders named after things you have not heard of yet, and a red job nobody mentions. The usual answer is a wiki page that went stale the week it was written.

Concierge answers from the instance itself, and makes three promises.

The welcome page, the tours, the learning paths and the assistant are all computed for the person looking, from their own permissions. A job they cannot read is not listed, not counted, not toured and not mentioned by the assistant. One setup serves the whole controller, from the newcomer with access to one folder to the administrator. The permissions involved are in docs/usage.md.

A tour walks across real pages of this instance and points at what matters: the job list, a healthy job, its build history, its last build, its console. Learning paths for people new to Jenkins, developers and DevOps engineers use this instance's jobs as their examples, and skip the pages a person cannot open. A team lead can pin the jobs that matter, with a note on each, without being an administrator.

A tour step on a real job. Tours follow both the classic Jenkins pages and the newer layout under Experiments, and skip a step whose part a page does not have, such as the job list on a dashboard made with another kind of view. More in docs/usage.md.

Ask "why did the last build fail?" on a job page and the assistant looks: the build, the end of its log, the job's history. It uses read-only tools that run as you, so it can never see more than you can. Logs are stripped of secrets before they leave the controller, and an administrator decides what kinds of data may be shared at all.

The chat floats over every page and knows which page you are on. Drag its corner to resize it, or expand it. Every answer says which tools it used, and job names in it link to the job.

The assistant is off until an administrator sets it up: an API key stored as a credential, a provider and model, and the Concierge/Assistant permission for the people who may use it. Setting up the assistant walks through it, including proxies and Configuration as Code.

When it is allowed to, the assistant can also propose running a job. It never starts anything itself: a card shows the job and every parameter value, and nothing runs until you click Run it. Everything is checked again at that moment, and the build is started as you.

The card is built from the stored proposal, never from the model's text. Password parameters can never be set by the assistant, and re-runs never copy secret values. See Starting builds from the assistant.

1. Manage Jenkins → Plugins → Available plugins, search for Concierge, and install it.
2. Open Concierge from the Jenkins header. The welcome page, tours and learning paths work straight away, with no AI and nothing sent anywhere.
3. Optionally, pin the jobs newcomers should start with: Edit welcome and start here.
4. Optionally, turn on the assistant: store the provider's API key as a Secret text credential, enable it under Manage Jenkins → System → Concierge assistant, and grant the Concierge/Assistant permission to the people who should use it. Step by step, including proxies and Configuration as Code: Setting up the assistant.

To try it without touching your own controller:

./scripts/demo.sh --anthropic      # or --openai --model M, --ollama MODEL, or nothing for no AI
./scripts/demo.sh --mode turbo --anthropic --n-jobs 100   # more plugins and a busier instance

That builds the plugin and starts a throwaway, secured Jenkins on http://localhost:8080/concierge/ with three users who each see a different instance. docs/demo.md has a walk-through of what to check as each of them, and docs/building.md covers building from source.

Once a provider and an API key are set, Concierge fetches the provider's own model list and shows each model with its price and where that price comes from: reported live by xAI, a dated list price shipped with the plugin, or one you set yourself. A model with no known price says so, rather than guessing.

Plain-HTTP base URLs get a warning unless the model runs on the same machine. A custom model id overrides the list, for gateways and fine-tuned models.

Every setting is documented in docs/usage.md, and Setting up the assistant covers the credential, the permission, proxies and Configuration as Code.

Concierge reads the whole instance and can talk to an AI provider, so it is built to a written set of rules, docs/security-design.md, which every change has to follow. In short:

• It acts as the person asking. Every lookup and every assistant tool runs with their permissions, never as SYSTEM. Job configuration needs Extended Read; installed plugins need System Read.
• Keys live in the Credentials plugin, and are only ever sent to the provider. Testing a connection, listing models and setting a base URL are administrator-only.
• Secrets do not leave. Only allowlisted fields are sent to a model, logs are redacted first, and build logs, job configuration and source control are each off until an administrator allows them.
• Untrusted text stays inert. Logs and commit messages cannot start anything, because a person has to confirm every build. Script Console, credentials, replay and workspaces are never offered to the model.
• Everything is audited: every question and tool call goes to a dedicated logger, without answers, tool results or keys. Question text is logged at FINE, for a log recorder, rather than to the system log.

To report a vulnerability, see SECURITY.md.

Everything on the welcome page is computed per request from what the current user can read, and never cached for anyone else. Tours are lists of steps, each naming a page and a CSS selector, run by a small script that every Jenkins page loads but which stays idle until you start a tour.

The assistant is a loop on the controller: it sends the conversation and a list of tools to the provider, runs the tools the model asks for as the signed-in user, and repeats until there is an answer or the tool-call limit is reached. Three pieces are worth knowing about:

The plugin ships no third-party libraries: HTTP uses the JDK client through Jenkins' proxy settings, and JSON a small strict parser of its own, because the one Jenkins bundles turns strings that look like JSON into objects.

Issues and pull requests are welcome. Read docs/CONTRIBUTING.md first, and docs/security-design.md for anything the assistant touches.

Every pull request must have all tests passing and zero known vulnerabilities in anything the plugin ships, both enforced by CI. Anything that shows instance data also needs a test proving that a user without permission cannot see it.

MIT.