Use a GitHub App for private Odoo module repositories

Why installation access

Private Odoo addons need authenticated repository access. Personal access tokens can provide it, but they tie a shared deployment path to one person’s credential and often carry more scope than the deployment needs.

The Tnion.SH GitHub App connection uses an installation owned by the workspace. During setup, GitHub shows which organization or account will install the App and which repositories it may access. The workspace then lists only repositories visible to that installation.

That model keeps sign-in OAuth separate from deployment access. Signing in with GitHub identifies a user; installing the GitHub App authorizes a workspace to read selected module repositories.

Connect the workspace

Start the GitHub installation from workspace settings. Tnion.SH creates a short-lived state value for the installation flow and validates it when GitHub returns. After the installation is associated with the workspace, project configuration can browse its repositories and branches.

Choose the repository that contains the custom addon directories. A valid Odoo module is detected by its manifest file, so the repository can contain one module or several sibling modules without a separate module list in the project settings.

Map repository branches

Each project stores a branch for Production, Staging, and Development. The default names match the stage names, but the mapping is editable. A team using main, release, and develop can state that policy directly:

Production   → main
Staging      → release
Development  → develop

The important part is not the naming convention. It is that the target branch comes from the instance stage, not from an ad-hoc input at deploy time. That makes the source of a deployment visible and repeatable.

What a module deploy does

The deploy service resolves a short-lived GitHub installation token for the project, selects the branch mapped to the instance stage, and checks that the instance has already been provisioned. It then fetches a shallow copy of the repository into the instance’s source directory and synchronizes it into the mounted addons directory.

Credentials are passed to the remote Git command through an environment value and are not written to the deployment log. After the checkout, the stored Git remote is reset to the public repository URL. Tnion.SH records the resulting commit SHA and commit message for the deployment outcome.

If addon manifests are present, the deploy runs an Odoo module update for the detected module names and then restarts Odoo. If there are no modules, it restarts the service without claiming that an update occurred. The deployment log preserves each stage of that operation so failures can be traced to repository access, checkout, module update, or restart.