How to package new releases of the module ?

Git flow to respect.

All evolutions or bugs resolution should be documented in one ticket on the bug tracker and on the POD documentation if the API changes. Each of those tickets should be done in a distinct Git branch that starts from the previous published version (the master branch). The release should also starts from it's own branch from master into which all other branchs will be merged inside it.

Build of the release.

When our release branch is done, a commit should be added that updates some data:

How to run integration (extra) tests?

Tests used in this module are messy because they need to create an LXC container and manipulate it. We recommend thus you to create a virtual machine with everything needed for running them.

How to create a VirtualBox image for running tests?

What to test?

LXC version 3 is not backward compliant with 2 one. Thus, it is important to test that any modification of the plugin will not add regression with LXC 2. This can be done by running all tests on a system that use LXC 2 and on a second one with LXC 3.

Debian 9.5 can be used as host for testing LXC 2, and Debian 10 as host for LXC 3.

How to run the tests?

Extra tests are the most important because it's the ones that manipulate concretely LXC containers. For running it, launch the dzil test command in the root of the git repository. This command will run both unit and integration (extra) tests.