Setting Up LXC CI/CD¶
This page is for the administrator who turns the LXC CI/CD on for an Application Definition. What each push then does is in How It Works.
Before you start, connect your git provider: an API token, an Incoming Webhook, and the webhook declared on the repository.
Turn it on¶
Open the Application Definition (Muppy › Applications › Applications › Application Definitions). In the form's header:
- Set Git Project ID and Git Project Name.
- Check Activate LXC CI/CD. The CICD LXC tab appears.
In the CICD LXC tab, set Upgrade Task. The task shipped with Muppy runs the upgrade
command of each kind of server, keeps its log, and marks the upgrade failed on a non-zero exit
code or an Odoo ERROR or CRITICAL line.
Configure the Test Servers¶
The sub-tab Test Servers decides what a push on a feature branch does. The settings to review first:
| Setting | Set it to |
|---|---|
| Provision Server on commit (Test) | Checked, to give each developer a Test Server at their first push on a branch. Unchecked, Muppy only deploys the Test Servers you create yourself. |
| Branch exclusion Regex | The branches that never get a Test Server. Add ^refs/tags/ for a GitHub repository. |
| Host Allocator (Test) | Where new Test Servers are placed. Empty, Muppy uses Application default LXC Allocator (Settings ▸ Muppy ▸ Applications). |
| Qualifier for Test Servers | The qualifier of the servers created. |
| Git Access Token (Test) | The git credential the servers fetch the code with. |
| Database source Strategy (Test) | How a new Test Server's database starts. |
| Default 'upgrade' command (Test) | The command run at each deployment, e.g. bin/odoo-ikb --update=all --stop-after-init --logfile=$UPGRADE_LOG_FILE |
Every setting is described in Configuration.
The sub-tabs Staging Servers and Production Servers hold the defaults of the deployments you launch by hand on those servers. See Deploying Staging and Production.
Map git users to Muppy users¶
Each push is attributed to the Muppy user whose Default User name or Remote User name equals the git login of the developer who pushed. A push from an unknown login does nothing.
For each developer, open their user form, tab Muppy, and set Remote User name to their
GitLab or GitHub login. Default User name is a Linux user name, lowercase with no
separator, so a login such as john.doe only matches Remote User name.
The Test Servers Muppy creates belong to that user.
Check it works¶
- Push a commit on a new feature branch.
- Open Muppy › Qs › Messages. A message named
Gitlab Webhook:'push' project='…' ref='PUSH on branch refs/heads/<branch>' by <login>.(orGithub Webhook…) appears, and is processed in the background. - Open it. Its journal says what Muppy decided: a server created, a deployment started, or why it stopped.
- With Provision Server on commit (Test) checked, the new Test Server appears under Muppy › Applications › Test Servers, and its provisioning runs in a message of its own.
Nothing in Messages? The call was refused before Muppy queued it. The provider's delivery log shows why: see Troubleshooting.