Jenkins Infra
This repository is the r10k control repository for the Jenkins project's own infrastructure.
Local development
The amount of testing that can be done locally is as follows:
bundle install
- To get the necessary gems to run tests locally, if you're unfamiliar with Ruby development you may want to use RVM to create an isolated Ruby environment./check
- Will run the rspec-puppet unit tests and the puppet-lint style validation. If you intend to run the rspec-puppet over and over, userake spec_standalone
to avoid re-initializing the Puppet module fixtures every time.
Vagrant-based testing
Pre-requisites
- Run the
./vagrant-bootstrap
script locally to make sure your local environment is prepared for Vagranting
Running server spec tests
We're using serverspec for on-machine acceptance testing. Combined with Vagrant, this allows us to create an acceptance test per-role which provisions and tests an entire Puppet catalog on a VM.
Pre-requisites
- Install Vagrant
- Install Vagrant plugins:
vagrant plugin install vagrant-serverspec
To launch a test instance, vagrant up ROLE
where ROLE
is one of the defined roles.
You can rerun puppet and execute tests with vagrant provision ROLE
repeatedly while the VM is up and running.
To just rerun serverspect without puppet, vagrant provision --provision-with serverspec ROLE
.
When it's all done, deprovision the instance via vagrant destroy ROLE
.
Updating dependencies
For reasons that Tyler will hopefully clarify at some point, this module maintains
the list of Puppet module dependencies in Puppetfile
and .fixtures.yml
. They
need to be kept in sync. When you modify them, you can have the local environment
reflect changes by running bundle exec rake resolve
.
Branching model
The default branch of this repository is staging
which is where pull requests
should be applied to by default.
+----------------+
| pull-request-1 |
+-----------x----+
\
\ (review and merge, runs acceptance tests)
staging \
|---------------o--x--x--x---------------->
\
\ (manual merge, auto-deploys to prod hosts)
production \
|----------------------------o------------->
The branching model is a little different than what you might be familiar with.
We merge pull requests into a special branch called staging
where we can run
Puppet acceptance tests from. Once somebody has code reviewed a pull request it
can be merged into staging
.
When a infra project team member is happy with the code in staging
they can
create a merge from staging
to production
. Once something has been merged
to production, it will be automatically deployed to production hosts.
Installing agents
For installing agents refer to the installing agents section of the PuppetLabs documentation.
Adding a new branch/environment
"Dynamic environments" are in a bit of flux for the current version (3.7) of Puppet Enterprise that we're using. An unfortunate side-effect of this is that creating a branch in this repository is not sufficient to create a dynamic environment that can be used via the Puppet master.
The enable an environment, add a file on the Puppet master:
/etc/puppetlabs/puppet/environments/my-environment-here/environment.conf
with
the following:
modulepath = ./dist:./modules:/opt/puppet/share/puppet/modules
manifest = ./manifests/site.pp
Contributing
#jenkins-infra
on the Freenode IRC network- INFRA project in JIRA.
- [email protected]