How LXC CI/CD Works¶
This page is for developers who push code. It says what each push does to your App Servers. The settings it names are on the Application Definition, tab CICD LXC; see Setting Up to configure them.
Which servers a branch reaches¶
The Application Definition names two branches. Every other branch is a feature branch.
| Branch | Where it is set | Servers it reaches |
|---|---|---|
| Default branch / depth | the Application Definition's main settings | Production Servers |
Default Staging branch (staging by default) |
CICD LXC › Staging Servers | Staging Servers |
| any other branch | — | your Test Servers |
Activate Auto deploy (Staging) and Activate Auto deploy (Prod) are off, so a push on those two branches stops there. Staging and Production Servers are deployed by hand: see Deploying Staging and Production.
A push on a feature branch¶
Muppy acts only when all of these hold:
- Your git login is known to Muppy. An administrator maps it to your Muppy user (see Setting Up).
- Activate Auto deploy (Test) is checked. It is by default.
- The branch does not match Branch exclusion Regex.
- re-Deployment Trigger (Test) is Every push (the default), or it is Comment tag and a
commit message of the push contains the Deploy Trigger comment tag (Test), e.g.
#mpy_deploy_test.
Then:
- You already have a Test Server for this branch: Muppy deploys it.
- You have none: Muppy creates one when Provision Server on commit (Test) is checked. It is off by default; without it, ask an administrator to create your server.
A Test Server belongs to the developer who pushed. Two developers who push on the same branch get one Test Server each. Its name carries the branch name, and its database starts as Database source Strategy (Test) says: an empty database, a seed, or the latest backup of an existing database.
Deleting a branch¶
Deleting a feature branch destroys its Test Servers, whoever owns them, when Deprovision on branch Delete is checked (the default).
The deletion reaches Muppy as a push with no commit. It is ignored when Activate Auto deploy (Test) is off, and when the trigger is Comment tag, since no commit message carries the tag.
Tags, pull requests and merge requests¶
- A GitLab tag does nothing to LXC App Servers.
- A GitHub tag reaches Muppy as a push on a branch named
refs/tags/<tag>. Add^refs/tags/to Branch exclusion Regex, or the tag gets a Test Server of its own. - A GitHub pull request creates no server. The push on its branch does.
- A GitLab merge request does the same by default. A beta mode, Provision Server on MR events (Experimental) — in the Test Servers sub-tab, shown in developer mode — gives each merge request a Test Server of its own, destroyed when the merge request is merged or closed. It needs Merge request events on the GitLab webhook, and works with gitlab.com only.
What a deployment does¶
A deployment runs these steps on the server, in order. The settings in bold turn each one on or off; Configuration details them.
- Stop the application (Stop Primary Before Deploy).
- Update the code to the head of the branch:
git fetch,git checkout,git pull, then the submodules. With Reset Repository, delete the repository and clone it again. - Run the builder (Launch builder). It always runs after a fresh clone.
- When an upgrade command is set: back the database up (Backup Before Upgrade), then run the command.
- Restart the application.
The code deployed is the head of the branch when the deployment runs, not the commit you pushed. Two pushes in quick succession can deploy the same head twice.
A deployment started by a push never duplicates the database: Duplicate DB Before Upgrade applies to deployments launched by hand.
Each deployment runs in the background, in a message of its own under Muppy › Qs › Messages:
Deploy branch 'feature-invoice' on server:'odoo18-feature-invoice-test-2f' with upgrade command:'…' and parameters defined in AppDef:'acme-erp'
Its record lands on the App Server, page Upgrades, list Deployments: state, git indexes, duration, and how long the application was down. A failed deployment can leave the application stopped; see When a deployment fails.