Jenkins main control repo for R10k
Go to file
R. Tyler Croy 9296cbe1e6 Classify all our existing agent'd nodes
The node == role mapping isn't /great/ but because we have nodes that server a
number of functions, we can't really say 1 logical role (e.g. 'webserver') can
map to 1 logical node
2014-05-01 15:24:32 -07:00
ci Clean out old fixtures "just in case" 2014-05-01 14:31:14 -07:00
dist Classify all our existing agent'd nodes 2014-05-01 15:24:32 -07:00
hieradata Adding webhook and eyaml management 2014-04-30 16:36:08 -07:00
manifests Classify all our existing agent'd nodes 2014-05-01 15:24:32 -07:00
spec Classify all our existing agent'd nodes 2014-05-01 15:24:32 -07:00
.fixtures.yml Add a Puppet report processor to ping IRC when reports are generated 2014-05-01 14:25:36 -07:00
.gitignore Properly generate `account` resources from our hiera data 2014-04-30 16:22:08 -07:00
Gemfile Properly run the rspec-puppet tests as part of the CI jobs 2014-05-01 13:32:15 -07:00
Gemfile.lock Upgrade to the latest puppetlabs_spec_helper from a slightly forked git repo 2014-04-30 20:46:02 -07:00
Puppetfile Add a Puppet report processor to ping IRC when reports are generated 2014-05-01 14:25:36 -07:00
README.md Add support for managing sudoers access across machines 2014-05-01 12:13:18 -07:00
Rakefile Turn lint warnings into failures! 2014-05-01 10:21:10 -07:00

README.md

Jenkins Infra

BuildStatus

This repository is the r10k control repository for the Jenkins project's own infrastructure.

NOTE: This repository and workflow are still a work in progress

Local development

The amount of testing that can be done locally is still a work in progress but thus far it's advisable that you do the following:

  • 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
  • bundle exec rake spec lint - Will run the rspec-puppet unit tests and the puppet-lint style validation. If you intend to run the rspec-puppet over and over, use rake spec_standalone to avoid re-initializing the Puppet module fixtures every time.
  • Vagrant-based testing - coming soon

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.

Contributing