Salt states used to run Jenkins tests.
The salt-jenkins state tree is used to configure and prepare the testing VMs used to run Salt's test suite on
Salt's Jenkins system. These states install the testing requirements needed
to execute the tests themselves, any packages and dependencies needed for particular module or state tests to
run, set up configuration files, and clone Salt into the /testing directory.
Occasionally, new packages need to be installed on the testing VMs to ensure that particular tests will run.
For example, if a contributor adds a test file for Salt's docker execution module, the docker package needs
to be installed on the test VMs. This repository is the place to perform that package installation by adding
a state.
You can clone this repository, and, as long as you already have salt installed, you can run this state tree
directly (instead of using gitfs).
For example:
salt-call state.sls git.salt pillar="{py3: true, test_transport: zeromq, with_coverage: true}"
The minion configuration file also needs to be edited to direct the file_roots to the salt-jenkins cloned
directory. For example, if the salt-jenkins repository was cloned directly into the /root dirctory, the
minion config file would look like this:
# /etc/salt/minion
file_roots:
base:
- /root/salt-jenkins
This is possible due to the fact that included in this state tree repository there are Saltfile and minion
configuration files which set everything up in order to run salt-call locally against this state tree.
The salt-jenkins project is welcome and open to contributions.
The salt-jenkins repository has a few openly maintained branches. These correspond to the actively maintained
release branches in the Salt project. This helps stabilize the testing
environments that the salt-jenkins states configure on the test VMs running at
jenkinsci.saltstack.com.
There is a node located in Salt's Jenkins installation configured to run the tests for each supported Salt
release branch. In turn, each node is configured to run the salt-jenkins state tree based on the Salt release
branch it supports.
For example, the Jenkins node labeled 2016_3 runs tests against the HEAD of the 2016.3 branch of Salt. This
same 2016_3 node is configured to run the salt-jenkins state tree using the 2016.3 branch of the
salt-jenkins repository.
Note: The "master" branch of the "salt-jenkins" repository is used to test the "develop" branch of Salt.
GitHub will open pull requests against Salt Jenkins's main branch, master, by default. Contributions to the
Salt Jenkins state tree should be added to the oldest supported branch that requires the change.
For example, imagine a new execution module was added to the develop branch in Salt, along with tests for
the new module. The new module requires a dependency that is not currently installed by the Salt Jenkins
states. The new state(s) would need to be added to the master branch of Salt Jenkins.
If new tests are written against an older release branch in Salt, such as the 2016.11 branch, then the
change for the Salt Jenkins states needs to also be submitted against the 2016.11 branch in the
salt-jenkins repository.
The Salt Jenkins repository follows a "Merge Forward" policy. The merge-forward behavior means that changes
that are submitted to older "release" branches will automatically be merged forward into the newer branches.
(The Salt repository follows this same behavior.) This makes is easy for contributors to make only one
pull-request against an older branch, but allow the change to propagate to all salt-jenkins branches as the
tests make their way forward in the Salt repository.
Here's a simple example of changes merging forward from older branches to newer branches, where the HEAD of
each branch is merged into the directly newer branch:
master *---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*------------>
/
/ (Merge Forward from 2016.11 to master)
/
2016.11 *---*---*---*---*---*---*---*---*---*---*---*---*
/
/ (Merge Forward from 2016.3 to 2016.11)
/
2016.3 *---*---*---*---*---*---*