> ## Documentation Index > Fetch the complete documentation index at: https://client-integrations-api-dev.sequen.ai/llms.txt > Use this file to discover all available pages before exploring further. # Connecting repositories > Install a GitHub App so Sequen can read your model code and propose changes back as pull requests, then point a Model Class at it. A **Model Class** is the unit RRI works on: your model code, its default configuration, a dataset and the metrics that matter. You can create one from an uploaded zip of the code, or point it at a GitHub repository. Pointing at GitHub is what makes the round trip work, because the same connection that reads your code proposes changes back as pull requests. ## Connect GitHub Sequen reads your code, and opens pull requests with the changes, through a GitHub App that you register on your own organization. There is no shared Sequen account and no personal access token to rotate. The App needs read and write access to contents and pull requests, and nothing else. Write access is used only to push the branch a pull request comes from and to open that pull request. Sequen never pushes to a default branch. The three permissions: | Permission | Level | Why | | - | - | - | | Contents | Read and write | Read the model code at the ref you choose, and push the branch a pull request is opened from. | | Pull requests | Read and write | Open the pull request, and read back its number and state. | | Metadata | Read | Mandatory for every GitHub App. | **1. Create the App** In your organization's settings, create a GitHub App and note its **App ID**. **2. Generate a private key** GitHub gives you a `.pem` file once. There is no way to read it back afterwards. **3. Enter it in Sequen** Open **Settings → GitHub** and enter the App ID and the contents of the `.pem`. The key is encrypted before it is stored and is never shown again. **4. Install it** Click **Install on GitHub**, choose your organization, and select the repositories Sequen may see. Selecting a subset is the usual choice. **5. Connect** Back in Sequen, click **Connect**. Sequen asks GitHub which installation that produced, so there is nothing to copy back. **Settings → GitHub** then names the organization it is connected to and the repositories the installation covers. Sequen reads the repository and ref a Model Class names, at the subpath it names, when the class is created and whenever an operator updates its code. It writes a branch and opens a pull request when an experiment is productionized. It does not read repositories the installation was not granted, does not delete branches and does not merge anything. To rotate the key, enter a new private key under **Settings → GitHub** and save. Work already in flight finishes on the key it started with, and everything after uses the new one. Revoke the old key on GitHub once the new one is connected. ## Point a Model Class at a repository Creating a GitHub-backed Model Class asks for four things: | | | | - | - | | **Repository** | Picked from the repositories the App was granted. | | **Ref** | The branch, tag or commit to read. A branch is the useful answer. | | **Subpath** | The directory to treat as the workspace root. Empty means the repository root. | | **Entry point** | The run command from that root, for example `bash run_train.sh` or `python -m pkg.train --config base.yaml`. | **Subpath makes a monorepo work.** Point it at `model_training/models/ranking` and the agents' workspace is that directory. Its README is the one the agents read, the entry point sits at the workspace root, and the rest of the monorepo is not shipped. **Use a branch as the ref.** A tag or a commit reads fine, but a pull request needs a branch to target. A class created from a tag or commit can run sessions but can never be productionized. The ref is also the base every pull request targets: create the class from `release/2.x` and its pull requests go to `release/2.x`. **The entry point is validated at create time** against the repository, so a typo is caught then and not on the first run. ## What the repository must provide Everything that defines a run lives in version control. The details are on [Model support](https://client-integrations-api-dev.sequen.ai/rri/model-support.md#what-your-model-code-must-provide). In short: * a git repository with a clean, training-runnable tree * one entry point, runnable from the workspace root * one configuration file the agents edit, with every tunable in it * training code that reports metrics to Sequen * a README that documents all of the above **The test:** if `git checkout && ` reproduces your numbers on a fresh machine, the repository is ready. ### Size limits | | Limit | | - | - | | Total size | 500 MiB | | Number of files | 20,000 | | Any single file | 100 MiB | Sequen enforces the limits when it reads your code. A class whose code is over any limit cannot be created or updated, and the error says which limit and what was measured. For a monorepo the **subpath** is measured, not the repository. Everything in the tree counts: docs, tests, notebooks and checked-in fixtures. Git LFS pointer files are refused by name when Sequen reads your code. A pointer is a few lines of text standing in for content git never fetched, so a run would read the text where the weights should be. Commit the content, or fetch it from storage as a dataset. ### Integration checks Sequen reads the code it holds for the class and reports on it under **Model Class → Code & configuration → Integration checks**. Nothing is executed and no GPU machine is reserved. | Check | What it means | | - | - | | `readme_present` | A README at the model-code root. | | `entrypoint_present` | The entry point names a file that is in the repository. | | `entrypoint_executable` | That file will run: committed as executable, or named with its interpreter. | | `config_detected` | A configuration file the agents can edit was recognized. | | `no_lfs_pointers` | No file is a Git LFS pointer. | | `size_within_caps` | The model code is within the size limits. | The size and LFS limits above are enforced when the code is read, so a repository that breaks them never reaches these checks. The checks report on the code the class already holds. Of the six, only `entrypoint_present` can stop a Model Class from being activated, and only when it fails outright: a command naming a file that is not there was never going to start. The other five are advice. An administrator can activate past a missing entry point with a reason that is recorded against their name. The checks do not tell you whether your training code reports metrics. Nothing runs it before your first session, so check that part by reading it against [Model support](https://client-integrations-api-dev.sequen.ai/rri/model-support.md#report-metrics). ## Keep the class current The class holds a private copy of your code, taken when it was created. It does not follow the branch. The **Code** tab shows how far behind the copy has fallen and offers **Update from GitHub**, which re-reads the current tip of the ref and moves the class's baseline forward. Updating changes the class's baseline only. Session branches, meaning every experiment any session has produced, are left exactly as they are. ## What comes back Productionizing an experiment pushes a branch named `sequen//` to your repository and opens a pull request from it into the class's ref. * **Nothing is pushed to your default branch**, and a push is never forced. * **The diff is the experiment, replayed onto your current base.** Sequen does not merge its private history into yours. It takes what the experiment changed and applies it to the tip of your base branch. A base that has moved elsewhere in the repository is fine. If it has moved on the same lines the experiment changed, the changes no longer apply, the pull request is refused, and the experiment has to be re-run against the current code. Updating the Model Class prepares the next run. It does not rescue that one. * **The pull request carries code and configuration only.** Trained weights are not part of it. See [Artifacts and getting models into production](https://client-integrations-api-dev.sequen.ai/rri/artifacts-and-serving.md). * **A `.gitignore` you ship is respected as yours.** A repository that ships none gets a synthetic one inside the class copy, and that file never travels back into a pull request. * **Keep generated files out of the tree.** Write checkpoints, datasets and other output to the output directory (see [Model support](https://client-integrations-api-dev.sequen.ai/rri/model-support.md#where-output-goes)), or they show up in the pull request. It is an ordinary pull request: your review, your CI, your merge. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.