Update install.pp

[nrvale0]

At least for me, bundle install was unreliable because of timeouts resolving / connecting to rubygems.org. The exec appears to be safe for multiple passes so I added a 'tries' attribute.

[atomaka]

Although I haven't had this happen with puppet-gitlab specifically, I have been running into this issue over the last several months with rubygems.org. Solution is hacky but seems reasonable enough.

I'll update once I get a chance to see why tests are failing.

[atomaka]

@nrvale0 Please update to pass puppet-lint tests. We ignore 80 chars, variable scope, and params class inheritance warnings.

[nrvale0]

More patches on the way. BTW, necessity of these hacks appears to be due to confluence of rubygems.org DNS reliability and Virtualbox NAT DNS caching. thx for the merge.

[igalic]

The generally accepted solution for rubygems going down is to setup a local rubygems mirror.
Might be overkill if gitlab is your only ruby project.
But then again, you're using puppet, so it's at least two. (still might seem unreasonable ;)

[sbadia]

You re-tries the puppet exec command 10x and bundle re-tries 5x, so in the worst case this command is executed 50x, maybe the good solution here, is to fail because we encounter a network/transversal issue no ?

[atomaka]

Failing vocally with a good error message might be a better solution than spamming bundle install and hoping we make it through the Gemfile before we pass our max tries.

[sbadia]

@atomaka +1

[sbadia]

@nrvale0 please, can you squash your commits in one ?

[sbadia]

Hi, ping! Any update on this PR ? :-)

[nrvale0]

Re being less aggressive on the retries: the purpose of the module is to get gitlab installed. In this case my own experience and the experience of other folks with whom I've spoken has been that rubygems.org DNS issues are not uncommon. In my mind, being less aggressive as to the number of retries doesn't move us toward the end solution of having gitlab installed and thus I lean toward leaving the ridiculous number of retries in the code.

As to squashing the commits, I'm not sure how to do that but I will investigate. If you have a doc/reference you can share that would help.

Thx!

[atomaka]

@nrvale0 man git-rebase for the command used to squash commits. http://git-scm.com/book/en/Git-Tools-Rewriting-History also provides an overview for rewriting history.

[nrvale0]

@atomaka : I rebased + squashed the feature branch and did a git push w/ force to my forked repo and it looks to have squashed all of the commits. Verifying that it now shows up as squashed in the PR....

[igalic]

@nrvale0 you'll have to git push --force to publish it in this space.

[nrvale0]

After the pull to master from canonical repo and rebase of the feature branch I'm uncomfortable submitting this PR without additional review and testing. I'll review and perhaps resubmit later.