# New Ansible playbook for installing GitLab

**URL:** <https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486>\
**Category:** Ansible Project\
**Tags:** ansible-project\
**Created:** [March 12, 2013, 1:56pm UTC](https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486 "2013-03-12T13:56:54Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [March 12, 2013, 1:56pm UTC](https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486/1 "2013-03-12T13:56:54Z")

</div>

If you used vars\_files or vars\_prompt, could it be done all in one pass?

---

<div class="post-metadata">

**Author:** ![Nigel\_Metheringham](https://avatars.discourse-cdn.com/v4/letter/n/3ec8ea/32.png) [@Nigel\_Metheringham](https://forum.ansible.com/u/Nigel_Metheringham)\
**Post date:** [March 12, 2013, 2:17pm UTC](https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486/2 "2013-03-12T14:17:18Z")

</div>

Michael DeHaan wrote:

> If you used vars\_files or vars\_prompt, could it be done all in one pass?

Very likely - the one I put together for a test lab installation of gitlab on Ubuntu is a single playbook (although with around a dozen templates and 3 scripts). I can dig it out if anyone is interested - would need to remove the 2 database and 1 account password obviously.

The scripts used - one does the ruby install (short circuiting if that version of ruby is already in place), one is a slightly modified version of the mysql lockdown script that ships with mysql (modified so I can run it non-interactively under ansible), and the last is an odds and sods bit of gitlab setup that ensures that ssh can connect to localhost and generally sets up gitolite (so this one handles part of the reason why Alexander's playbook cannot run in one pass).

The bit I haven't done is a gitlab upgrade of an existing installation. I suspect that might be hard to do well - it may even be easier to just backup, zilch the existing install, install new, restore from backup.

&nbsp;&nbsp;Nigel.

---

<div class="post-metadata">

**Author:** ![Nigel\_Metheringham](https://avatars.discourse-cdn.com/v4/letter/n/3ec8ea/32.png) [@Nigel\_Metheringham](https://forum.ansible.com/u/Nigel_Metheringham)\
**Post date:** [March 14, 2013, 1:09pm UTC](https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486/3 "2013-03-14T13:09:40Z")

</div>

Alexander Teinum wrote:

> &nbsp;&nbsp;&nbsp;&nbsp;Very likely - the one I put together for a test lab installation of  
> &nbsp;&nbsp;&nbsp;&nbsp;gitlab on Ubuntu is a single playbook (although with around a dozen  
> &nbsp;&nbsp;&nbsp;&nbsp;templates and 3 scripts). I can dig it out if anyone is interested -  
> &nbsp;&nbsp;&nbsp;&nbsp;would need to remove the 2 database and 1 account password obviously.
> 
> It would be great if you made it available.

I have put a lightly modified (removed/concealed some site specific stuff), onto github at  
&nbsp;&nbsp;[https://github.com/nigelm/ansible\_sample\_gitlab](https://github.com/nigelm/ansible_sample_gitlab)

> &nbsp;&nbsp;&nbsp;&nbsp;The scripts used - one does the ruby install (short circuiting if that  
> &nbsp;&nbsp;&nbsp;&nbsp;version of ruby is already in place), one is a slightly modified  
> &nbsp;&nbsp;&nbsp;&nbsp;version  
> &nbsp;&nbsp;&nbsp;&nbsp;of the mysql lockdown script that ships with mysql (modified so I can  
> &nbsp;&nbsp;&nbsp;&nbsp;run it non-interactively under ansible), and the last is an odds and  
> &nbsp;&nbsp;&nbsp;&nbsp;sods bit of gitlab setup that ensures that ssh can connect to localhost  
> &nbsp;&nbsp;&nbsp;&nbsp;and generally sets up gitolite (so this one handles part of the reason  
> &nbsp;&nbsp;&nbsp;&nbsp;why Alexander's playbook cannot run in one pass).
> 
> Did you find a way to skip the Ruby installation step using only Ansible  
> � i.e. no external shell scripts? I read about the conditional  
> execution, but I didn�t find a way to write what would resemble an  
> if-block for a set of tasks.

No solution to that right now.  
Only one I can think of would be to gather some custom facts including the ruby patch level.

With the changes to command/shell coming up you would be able to use a custom exit code from the script to mean that no changes were made.

&nbsp;&nbsp;Nigel.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [March 14, 2013, 2:14pm UTC](https://forum.ansible.com/t/new-ansible-playbook-for-installing-gitlab/12486/4 "2013-03-14T14:14:51Z")

</div>

If you don't want to write a fact, you can always use 'register'.
