Connecting Source Code Insight with GitHub
Connecting GitHub tells QaaS what changed in your game between test runs. Test results tell you what broke; the GitHub connection tells you what was touched, so the two can be read together on the Change Impact page.
This is a separate integration from the QaaS Reporter. The Reporter uploads test results. The GitHub App uploads change history. Neither depends on the other, and you can run either one alone.
What you get, and what you do not
Section titled “What you get, and what you do not”With the App installed and repositories mapped:
- Pull requests become change records. Each PR’s changed files are matched against your test domains, so you can see which areas of the game a change reaches before it merges.
- Pushes to your default branch become builds, giving test runs a version to attach to and a history to compare against.
- Change Impact and the predictive views stop showing sample data and start showing yours.
What it does not do: it does not read your source code into QaaS, run anything in your repository, write to your repository, or open issues. It reads metadata about changes. The permissions below are the whole of it.
Permissions the App requests
Section titled “Permissions the App requests”The App requests the permissions below. Have them ready for whoever approves installs on your GitHub organization.
| Permission | Level | Why |
|---|---|---|
contents | Read | Retrieve the list of files a change touched. |
pull_requests | Read | Detect PRs opened, updated and reopened. |
metadata | Read | Granted implicitly by GitHub alongside any repository permission. Not a separate request. |
There is no write permission of any kind, and no access to Actions, secrets, packages, or organization administration. The App subscribes to two webhook events, pull_request and push.
You choose which repositories the App can see at install time, and you can change that selection later without reinstalling.
1. Start from QaaS
Section titled “1. Start from QaaS”Sign in to QaaS and open Integrations. On the GitHub card, click Connect GitHub.
QaaS generates a short-lived, signed link and sends you to GitHub. The link identifies your company and expires quickly, so if you leave the tab open for a while and come back, start again from this step instead of reusing the old link.
2. Choose repositories on GitHub
Section titled “2. Choose repositories on GitHub”GitHub asks which account or organization to install into, then whether to grant access to all repositories or a selected list.
Select only the repositories you want QaaS to see. “All repositories” works, but a narrower list is easier to justify to a security reviewer and easy to widen later.
Approve the install. GitHub sends you back to QaaS.
3. Map repositories to projects
Section titled “3. Map repositories to projects”QaaS lists the repositories the installation can see and asks which QaaS project each one belongs to.
If your company has exactly one project, every repository is mapped to it automatically. You can still change it.
Mapping is what makes a repository’s changes appear on the right game’s Change Impact page. An unmapped repository is not an error, and nothing breaks: its events are received and discarded, and you can map it later.
4. Map paths to test domains
Section titled “4. Map paths to test domains”This is the step that determines whether Change Impact says anything useful, and it is the one most easily skipped.
A domain is a functional area of your game, and it is what QaaS groups test results under. To connect a code change to a domain, QaaS needs to know which paths belong to which domain. Open Project settings > Domain mapping and give each domain one or more path patterns:
Netcode Assets/Scripts/Netcode/**Combat Assets/Scripts/Gameplay/Combat/**HUD Assets/Scripts/UI/**Without these patterns, every change matches zero domains. The integration still works, the PRs still arrive, and every one of them reports no impact, which reads as “this change is safe” when it actually means “nothing was mapped.”
Two things to leave out deliberately:
- GameDriver’s own SDK files. They are test tooling, not your game.
- Your test project itself. A change to a test is not a change to the thing under test, and counting it as one flatters your coverage figures.
Third-party packages shipped inside your project, such as Unity’s bundled TextMesh Pro, are usually worth excluding for the same reason.
5. Confirm it worked
Section titled “5. Confirm it worked”Open a pull request against a mapped repository, touching a file that matches one of your domain patterns.
Within a minute or so it should appear in Change Impact for that project, showing the domains its files reach. If the PR appears but reports no domains, the connection is fine and the path patterns are the problem: go back to step 4 and check that your patterns match your actual directory layout.
Builds only come from your default branch
Section titled “Builds only come from your default branch”Pushes create builds only on the repository’s default branch. A push to any other branch is received and deliberately discarded. If your team does its work on a long-lived branch that is not the default, no builds will be recorded from it, and test runs will have no build history to compare against.
Pull requests are not affected by this. A PR from any branch produces a change record normally.
If your workflow keeps its real activity off the default branch, change the repository’s default branch in GitHub to the one you actually build from.
Troubleshooting
Section titled “Troubleshooting”“That GitHub connect link expired.” The signed link is short-lived. Return to Integrations and click Connect GitHub again.
The install succeeded but no repositories are listed. The installation was created on a different account or organization than you expected, or was scoped to repositories you cannot see. Check the App’s installation settings in GitHub and confirm which account it landed on.
Pull requests appear, builds do not. Almost always the default-branch rule above.
Nothing appears at all. Confirm the repository is mapped to a project in QaaS, and that the change was a PR opened, updated or reopened. Only those three actions create change records; merges and closes do not.
Every change reports zero domains. Path patterns are missing or do not match. Patterns are matched against paths as they appear in the repository, so Assets/Scripts/** and src/Assets/Scripts/** are not interchangeable.
We removed a repository and want its history gone. Removing the repository from the installation stops new events and marks the mapping stale, but keeps what was already collected. Ask GameDriver if you need the history removed as well.