How to Connect a Code Base

Documentation lags the product. A customer can ask about something the code already does that the knowledge base never got around to describing — and until now, a Specialist had nowhere to look for the answer. A code base closes that gap: it’s a GitHub repository that Atender copies in, redacts, and keeps in sync, so a granted Specialist can search it the same way it searches the knowledge base and answer in product terms.

Connecting a code base does not put source code in front of customers. It gives Specialists a search/read/list tool over a private, redacted copy of the repository, so they can turn “does the product do X” into a confident answer instead of a shrug.

Before you start

• You’ll need the API & integrations permission in Atender — Owner and Team Lead hold it by default — and permission to install a GitHub App on the organization or account that owns the repository.
• The repository doesn’t need to be public — the connection is authorized per-repository through GitHub, not by making anything world-readable.

Connect a repository

1. Go to Settings → Integrations → Code bases.
2. Click Connect GitHub.
3. You’ll be sent to GitHub to authorize Atender Code Reader — a separate GitHub App from any issue-tracker integration you may already have connected. It’s deliberately read-only and asks for nothing beyond repository read access, so authorizing it never grants write access to your issues or code.
4. Pick the repository you want GitHub to make available, then return to Atender.
5. Back on the Code bases page, choose it in the Repository dropdown and click Add code base. The picker stays open so you can add several in a row; Done closes it.

Atender proves that you’re actually able to reach the installation you’re naming before binding it to your tenant, so you can’t accidentally (or otherwise) attach a repository that belongs to someone else’s GitHub account.

What happens after you connect

Initial sync. As soon as a repository is added, Atender pulls it in, strips anything on the exclude list, masks values that look like secrets, and stores the result as an archive. This first pass can take a few minutes on a large repository.

Sync on push. After the initial sync, Atender keeps the code base current automatically — a push to the branch the code base tracks (its default branch, unless you set another) triggers a new sync without you doing anything. Pushes to other branches are ignored, and so are pushes to a code base that has been disabled.

Status. Each code base shows one of these states:

• Connected — Latest sync succeeded; Specialists can search this code base.
• Syncing — A sync is in progress — either the initial pull or one triggered by a push, by saving new excluded paths, or by Sync now.
• Error — The last sync failed. The code base keeps serving the last good copy it has, if any, until a sync succeeds again.
• Disabled — The code base isn’t searchable. This can be something you set, or it can happen automatically — for example if the GitHub App is uninstalled, suspended, or the repository is removed from the installation. In that case Atender also deletes the stored archive rather than leaving a customer’s source sitting in storage after access has been revoked on GitHub’s side.

File and byte counts. Open a code base and its detail panel reports Files, Size, the count of Masked values hidden on the last sync, and the Commit it last synced — so you can sanity-check that the sync captured what you expected.

Excluded paths. In that same panel you can set glob patterns, one per line, to keep paths out of the archive entirely — vendored dependencies, generated files, anything you don’t want indexed at all. Save changes starts a sync for you, because the patterns only take effect once one runs.

Sync now. Don’t want to wait for the next push? Trigger a sync on demand, from the row’s refresh button or from the detail panel.

Remove. Removing a code base deletes the stored archive along with the connection. It stops being searchable immediately, and the copy Atender was holding is gone, not just hidden.

Who can see what

Connecting a repository doesn’t expose it to customers, and it doesn’t hand it to every Specialist either:

• Only a Specialist that’s been granted the code search tools can use them — the same way any other tool is assigned, not something that comes on by default with a connected code base.
• Holding the tools is not enough on its own. Each Specialist also needs this repository ticked on its own Knowledge → Code bases card; a Specialist with the tools and no grant gets an error on a code search rather than reading everything. See Link a Specialist to a code base.
• A granted Specialist reaches the code through three tools — searching, reading a file, and listing files — over a working copy, not the live repository.
• Answers are expected in product terms. No file path, source snippet, or internal name is meant to reach the customer; the Specialist uses what it finds in the code to describe what the product does, not to quote the code back.
• Revoking access on GitHub (uninstalling the app, suspending it, or removing the repository from the installation) disables the code base and removes the stored copy — it doesn’t sit around readable after you’ve taken access back.

If a sync shows Error

An Error status means the last sync didn’t complete cleanly — the code base keeps answering from whichever copy it last synced successfully, if one exists, rather than presenting a partial or broken sync as good. Trigger Sync now once you’ve addressed the cause (for example, a repository that grew past what a sync can handle, or an access problem on GitHub’s side). If the code base has never synced successfully, it has nothing to search until a sync succeeds.