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 admin access in Atender 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
- Go to Settings → Integrations → Code bases.
- Click Connect GitHub.
- 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.
- Pick the repository you want GitHub to make available, then return to Atender.
- Choose it from the list and add it as a code base.
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 repository triggers a new sync without you doing anything.
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, a saved change, or 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. Each code base reports how many files and how many bytes made it into the archive after exclusions and redaction, so you can sanity-check that the sync captured what you expected.
Exclude globs. You can set glob patterns to keep paths out of the archive entirely — vendored dependencies, generated files, anything you don’t want indexed at all. Save your patterns and they take effect on the next sync.
Sync now. Don’t want to wait for the next push? Trigger a sync on demand — useful right after you change exclude patterns, since a saved pattern only applies once a sync actually runs.
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.
- 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.