Connecting repositories

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.

Create the App

In your organization’s settings, create a GitHub App and note its App ID.

Generate a private key

GitHub gives you a .pem file once. There is no way to read it back afterwards.

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.

Install it

Click Install on GitHub, choose your organization, and select the repositories Sequen may see. Selecting a subset is the usual choice.

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. 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 <commit> && <one command> 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.

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/<model-class>/<experiment-id> 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.
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), or they show up in the pull request.

It is an ordinary pull request: your review, your CI, your merge.

Get Started

Web Pixel

Hosted RRI