Prior to this commit, the control-repo was an example of the
structure of a control repo but it also included puppet code to
help setup code manager and instructions to get that all setup
in a very specific way.
This was great for users that wanted to follow those instructions
exactly but wasn't great for people just looking for an example to
start from.
After this commit, the control-repo will be just an example once
again and a new repo somehwere else will pop up to provide the
explicit instructions on how to use the example with code manager.
There are links added to puppetlabs/control-repo to a new repo
that will have a version of the code that once lived in
puppetlabs/control-repo
Prior to this commit, there was a stash profile in the site dir
of this control-repo.
After this commit, the profile has been moved to it's own repo
where it can be used more generally and not tightly coupled to this
repository.
Prior to this commit, there was a gitlab profile in the site dir
of this control-repo.
After this commit, the profile has been moved to it's own repo
where it can be used more generally and not tightly coupled to this
repository.
As a result, the gitlab role has been removed from this repository
as well.
Prior to this commit, the puppetmaster profile was embedded in this
control-repo.
After this commit, the puppetmaster profile is moved out into its
own module.
Prior to this commit, these two files were laying around but not used.
The code manager template was missed when the code was moved into
a module and the function was added a while ago but then never
put to use.
After this commit, the codebase is a little lighter without these
stale files.
Prior to this commit the functionality to setup the either code
manager or zack/r10k was tightly coupled to this control-repo. In
an effort to make that functionality useful to more people we're
splitting it into a dedicated module.
After this commit, the pe_code_manager_webhook module will contain all logic
around setting up the webhook while this control-repo will still
gloss over the details needed to get everything in PE setup correctly
to use that module.
This commit removes the files associated with the profile including
some custom functions that were only there to make it work.
This commit removes the all_in_one_pe_2015_2 role as it was exactly
the same as the all_in_one_pe role.
This commit modifies all_in_one_pe to use the pe_code_manager_webhook module
instead of the profile.
Shouldn't this be profile::git_webhook as in all_in_one_pe.pp since the abstraction logic is located there?
Either that or the profile::zack_r10k_webook is missing from the location specified?
Prior to the this commit, if you were using the code_manager
profile on a split install it would incorrectly try to curl the
NC api on the master node.
After this commit, it should correctly curl the hostname of the NC
This has no impact on the functionality of the code on a monolithic
PE installation.
Prior to this commit there was a requirement for the user of this
repo to create a RBAC role in order for code manager to work.
After this commit an exec statement will curl the RBAC API to
create the role one time and hopefully it works otherwise the exec
will not run again.
Prior to this commit, if you upgraded from a previous version of
the control-repo both code manager and zack/r10k webhook would
be running and ready to receive data. This can present problems
if the webhook isn't disbled in the git management system is
sending data to both receivers.
This commit adds rudimentary ability to break the zack/r10k
webhook so it can't receive data.
Prior to this commit there were two possible webhooks
- zack/r10k webhook
- code manager
I moved these two profiles under git_webhook and choose the correct
one based on the version of PE being used.
As a safety hatch, I provide the $force_zack_r10k_webhook param
on profile::git_webhook in case someone needs to continue using it
instead of code manager.
