On 2014-05-18 17:14, Jeremy T. Bouse wrote:
On 05/18/2014 07:47 AM, David Schmitt wrote:
Hi,
thank you Jeremy for sharing your setup. That looks very nice indeed!
I do have a few questions, which might help further the understanding of
r10k deployments.
* How is r10k used with local vagrant development?
I guess I would have to better understand in what capacity you are
thinking with local vagrant development. All r10k is doing is checking
out the repo to a cached directory then deploying the branches out as
environment directories under the specified basedir. Likewise the
Puppetfile itself is also understood by librarian-puppet which can
install the modules specified into a modules/ sub-directory and is
actually part of my local workflow to test and ensure I have
dependencies met when including a new module since r10k doesn't do the
dependency check itself and simply installs only what's specified in the
Puppetfile.
So the answer I was looking for seems to be "I'm using puppet-librarian
for local development."?
* How do you manage local patches to puppet-forge modules?
I approach modifications as I do as a Debian Developer, and if I need
to patch a forge module I've forked it, fixed it and submitted a pull
request back to the author. The Puppetfile format allows for both
specifying the forge module or a git repo and with r10k > 1.1.3 it
handles switching between a forge module declaration and a git repo so
until the patch is accepted I can point the module at the modified git repo.
Seems to work out well for you, as I haven't seen any local forks in
your Puppetfile.
Some notes from my side:
* jenkins with multiple branches: depending on the complexity of your
jobs, and non-functional requirements, you might consider using
jenkins-job-builder to create separate jobs for each branch, or use
one of the more built-in mechnisms like the GIT_BRANCH environment
variable or job parameters (when triggering externally).
I'll have to take a look at jenkins-job-builder and see if it can't
provide the solution I'm looking for. My job that triggers the r10k
deployment is using GIT_BRANCH to decide which environment to update.
The trick is in the promotion trigger as I currently have to pass the
next branch to promote to and the actual job itself for development &
staging which have this promotion trigger are locked by specifying the
"Branches to build" within the job. The production branch deploy job is
almost identical with the exception it uses the git publisher to tag the
run on success and it doesn't have the promotions.
Wouldn't everything except "development" promote (i.e. integrate) to
"development" first, and then "development" is released as "production"?
OTOH that seems excessive when a primary use case is fast-forwards of
development to the developer's HEAD, after testing it somewhere.
Regards, David
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5378D79B.2020108%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
