geerlingguy / ansible-role-gitlab

Ansible Role - GitLab

Home Page:https://galaxy.ansible.com/geerlingguy/gitlab/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Invalid gitlab.rb file generated

dkolepp opened this issue · comments

I am trying to use the role (v3.1.0) to install GitLab 13 (13.12.4-ce.0.el8) and am getting a resulting generated gitlab.rb file with:

letsencrypt['contact_emails'] = "["gitlab@example.com"]"

The line above comes from Line 24 of the templates/gitlab.rb.j2 file:

letsencrypt['contact_emails'] = "{{ gitlab_letsencrypt_contact_emails | to_json }}"

the to_json filter produces quotes (") - inside of other quotes.

Without modification of the gitlab.rb file, the gitlab-ctl reconfigure command fails:
image

When I remove the quotes, the gitlab-ctl reconfigure command works continues as expected (- except that I did not intend to install Let's Encrypt certs, and so I get other Let's Encrypt configuration errors...)

The Let's Encrypt section of the file is included wrongly because the default value of gitlab_letsencrypt_enable is "false" - which appears to be treated as a string and not a boolean value (from what I can tell). So, it is included in the rendered gitlab.rb file on the remote gitlab server.

Submitting a PR for consideration shortly ...

Experiencing the same issue.
The quoting breaks the parsing of the gitlab.rb file.
PR #177 contains a fix.

commented

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

commented

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

I hate this bot. The issue is not fixed, it's being worked on #177.

I agree with @JulienPalard. This issue causes an invalid configuation file, breaking Gitlab reconfiguration and updates without manual intervention. Which is exactly a use case one would use Ansible for: the automation.
While I understand closing stale issues, because of bandwidth restrictions, this bot is being overzealous. A fix is available via PR. So you can absolutely use that if you are used to working with git.
I appreciate @geerlingguy's work a lot, and point out his excellent work to all the people I teach about Ansible, so I hope he can have a look at this issue in person.
Otherwise I hope he reconsiders assigning some form of maintainership to somebody. That person or group doesn't need to have control of the master branch, some develop or staging branch will do for the community. Keeping @geerlingguy as "benevolent dictator for life" sounds good to me. 😉

commented

This issue is no longer marked for closure.

The licenses on my repos are excessively free (MIT is about as 'do what you want' as it gets) to ensure people can easily fork and use the role to do whatever they want.

Note that I maintain these roles for my own use, so if something breaks that affects my use case, I'm often quicker to fix it. If something breaks someone else's workflow, and it doesn't affect mine, I might not get around to it for a while.

I have the stale bot around because for every issue like this one, there are 50 more that are non-helpful support requests that I simply cannot spend my time helping with (especially since about 95% of those never get a response even if I do spend 10 minutes trying to help the lost soul), and I don't want to leave them out to languish forever :( — my time is the most important thing I can control, and unfortunately, even though many people absolutely hate the stale bot, I would not maintain even a tenth of the projects I 'maintain' (for better or worse) without it ;)

Thanks for taking the time to look at this @geerlingguy . We appreciate it a lot! 😄

The stale bot is not in question and I understand exactly how you feel: time is valuable. I feel the same way.
Having the repos excessively free is something we all thank you for. While I/we could fork it I do stand by my remark to perhaps (re)consider some form of maintainership on your more popular roles (such as this one). Some staging branch would help to keep it centralized instead of creating yet another copy to maintain.

Of course it's your repo, your work, and your decision 👍
Thanks again for your efforts!

Thanks for the explanation about the bot @geerlingguy, I'll update my opinion on it.

(While I'm off-topic: Thanks for all the things you share, I do appreciate it!)

With #177 merged this can now be closed.

Thanks to everyone working on this ♥