Well I've been using an initial solution for the past month or two which
seems to be working ok.
I have a custom puppet function that reads the version of the artifact
being deployed and I add that to the mcollective facts.yaml file at the
same time that the artifact is deployed. I've also got
I'll have a play around in the next few days when I get a chance and report
back
I'm thinking a little foreground agent is probably the way to go for now as
a "quick fix", and then I'll work on something cleaner once we start phase
2 in a couple of months
Thanks for the pointers, much apprecia
- Original Message -
> From: "Tom Poulton"
> To: puppet-users@googlegroups.com
> Sent: Monday, May 13, 2013 4:06:56 PM
> Subject: Re: [Puppet Users] MCollective deployment pattern
>
> Thanks for the quick reply
>
> The -W environment=foo tip is ver
Thanks for the quick reply
The -W environment=foo tip is very useful and definitely solves one
problem. I appreciate that the synchronous part could get pretty nasty,
rather you than me :) In the meantime have you got any tips on the best
(most reliable) way to check up on triggered runs, you m
- Original Message -
> From: "Tom Poulton"
> To: puppet-users@googlegroups.com
> Sent: Monday, May 13, 2013 3:38:34 PM
> Subject: [Puppet Users] MCollective deployment pattern
>
> Hi all
>
> I have a scenario in mind for MCollective and I was looking
Hi all
I have a scenario in mind for MCollective and I was looking for
some feedback
The basic idea is this:
1) A code push to Git triggers a Jenkins build
2) A successful build triggers automatic deployment to an automated
functional test environment
3) Functional tests run automatically and t
