voxpupuli / puppet-gitlab Goto Github PK
View Code? Open in Web Editor NEWPuppet module to manage Gitlab (Omnibus)
Home Page: https://forge.puppet.com/puppet/gitlab/
License: BSD 3-Clause "New" or "Revised" License
Puppet module to manage Gitlab (Omnibus)
Home Page: https://forge.puppet.com/puppet/gitlab/
License: BSD 3-Clause "New" or "Revised" License
Hi,
Using vshn/gitlab v1.5.0
on CentOS 7
with gitlab-ce 7.14.1
omnibus package it seems that the gitlab-runsvdir
systemd service is not running, and /usr/bin/gitlab-ctl
seems not able to start the gitlab services without having it running. As gitlab-runsvdir
systemd service is not enabled gitlab also does not start automatically on boot.
root@sources ~ # /usr/bin/gitlab-ctl status
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # /usr/bin/gitlab-ctl start
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl status gitlab-runsvdir.service
gitlab-runsvdir.service - GitLab Runit supervision process
Loaded: loaded (/usr/lib/systemd/system/gitlab-runsvdir.service; disabled)
Active: inactive (dead)
root@sources ~ # systemctl enable gitlab-runsvdir.service
ln -s '/usr/lib/systemd/system/gitlab-runsvdir.service' '/etc/systemd/system/basic.target.wants/gitlab-runsvdir.service'
root@sources ~ # /usr/bin/gitlab-ctl start
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl start gitlab-runsvdir.service
root@sources ~ # /usr/bin/gitlab-ctl status
run: ci-redis: (pid 1533) 4s; run: log: (pid 1530) 4s
run: ci-sidekiq: (pid 1537) 4s; run: log: (pid 1534) 4s
run: ci-unicorn: (pid 1547) 4s; run: log: (pid 1541) 4s
run: logrotate: (pid 1544) 4s; run: log: (pid 1539) 4s
run: nginx: (pid 1536) 4s; run: log: (pid 1532) 4s
run: postgresql: (pid 1545) 4s; run: log: (pid 1542) 4s
run: redis: (pid 1535) 4s; run: log: (pid 1531) 4s
run: sidekiq: (pid 1540) 4s; run: log: (pid 1538) 4s
run: unicorn: (pid 1546) 4s; run: log: (pid 1543) 4s
It looks like that the service is explicitely disabled in manifest/params.pp and is using custom start/stop commands directly calling /usr/bin/gitlab-ctl that seems not to be working without the systemd service, is this the expected result am I the only having a problem with this configuration?
Enabling and starting the service manually does fix the problems, gitlab-ctl
will be able to restart the services and gitlab will run on boot as expected.
Best,
Baptiste
Version 7.14 of Gitlab now supports Mattermost (http://doc.gitlab.com/omnibus/gitlab-mattermost/). A new parameter must be specified in /etc/gitlab/gitlab.rb:
mattermost_external_url 'http://mattermost.example.com'
This parameter should be added to the template and the init module. Maybe a hash of parameters would be nice so it could handle future new parameters.
Will there be Version support in the module?
Currently latest works but see few caveats:
Could not find option how to add "registry_external_url" to gitlab.rb config.
class { 'gitlab':
external_url => "https://git-ig.cz.avg.com",
registry_external_url => "https://git-ig.cz.avg.com:4567",
...
}
gitlab:
registry_external_url: "https://git-ig.cz.avg.com:4567"
gitlab::gitlab_rails:
webhook_timeout: 10
gitlab_default_theme: 2
registry_external_url: "https://git-ig.cz.avg.com:4567"
...
creates:
gitlab_rails['registry_external_url'] = 'https://git-ig.cz.avg.com:4567'
external_url 'https://git-ig.cz.avg.com'
registry_external_url "https://git-ig.cz.avg.com:4567"
############################
# gitlab.yml configuration #
############################
gitlab_rails['gitlab_default_theme'] = 2
...
Hi,
On Debian Wheezy (7) after installing the error on each puppet run:
Error: Execution of '/usr/sbin/update-rc.d gitlab-runsvdir defaults' returned 1: update-rc.d: error: unable to read /etc/init.d/gitlab-runsvdir
I have tried purging the package and running from scratch with the same result. The file /etc/init.d/gitlab-runsvdir does not exist.
Hiera data:
gitlab::external_url: 'http://gitlab.XXXX'
gitlab::gitlab_rails:
time_zone: 'UTC'
gitlab_email_enabled: false
gitlab_default_theme: 4
gitlab_email_display_name: 'Gitlab'
gitlab_email_from: 'github@XXXX'
gitlab::sidekiq:
shutdown_timeout: 5
Class call:
class { '::gitlab':
external_url => 'http://gitlab.XXXX',
}
Please let me know if you need any more info.
Thanks
Gitlab has progressed a lot in the last months. The file templates/gitlab.rb.erb needs to be revised and aligned to the template found in Omnibus.
Gitlab 8.5.5
Module 1.8.0 release
On a fresh provision:
==> gitlab: Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]: Failed to call refresh: Could not restart Service[gitlab-runsvdir]: Execution of '/usr/bin/gitlab-ctl restart' returned 1: ok: run: gitlab-workhorse: (pid 7493) 1s
==> gitlab: ok: run: logrotate: (pid 7499) 0s
==> gitlab: timeout: down: nginx: 0s, normally up, want up
==> gitlab: ok: run: postgresql: (pid 7573) 0s
==> gitlab: ok: run: redis: (pid 7582) 1s
==> gitlab: ok: run: sidekiq: (pid 7594) 0s
==> gitlab: ok: run: unicorn: (pid 7599) 0s
==> gitlab: Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]: Could not restart Service[gitlab-runsvdir]: Execution of '/usr/bin/gitlab-ctl restart' returned 1: ok: run: gitlab-workhorse: (pid 7493) 1s
==> gitlab: ok: run: logrotate: (pid 7499) 0s
==> gitlab: timeout: down: nginx: 0s, normally up, want up
==> gitlab: ok: run: postgresql: (pid 7573) 0s
==> gitlab: ok: run: redis: (pid 7582) 1s
==> gitlab: ok: run: sidekiq: (pid 7594) 0s
==> gitlab: ok: run: unicorn: (pid 7599) 0s
Second provision is okay
Although Amazon Linux is based on RHEL, they're using different release naming schema than RHEL and therefor this module seems incompatible for Amazon AMI.
I think, OS selection case should be modified as includes Amazon Linux $::operatingsystemmajrelease value.
Here is an example facter output from an Amazon AMI:
operatingsystem => Amazon operatingsystemmajrelease => 2015 operatingsystemrelease => 2015.09
Got my gitlab on /, and I want it on a diffrerent partition, say /data. going over the code I don't see a way to pass that parameter to the omnibus. I'd move and symlink it, but gitlab would not run on a path with any part of the path being a symlink.
On that matter, can I get the entire /var/opt/gitlab move into /opt/gitlab/githome or any random path as needed?
In omnibus this was deprecated but using puppet manually configuring options via UI probably isn't the best solution:
7.9.0
DEPRECATION: 'gitlab_signup_enabled', 'gitlab_signin_enabled', 'gitlab_default_projects_limit', 'gravatar_enabled' are deprecated, settings can be changed in admin section of GitLab UI
Can this be confirmed as working or not?
Every hiera directive for gitlab.rb I need works for me except
gitlab::registry_external_url: 'somedomain.com:4567'
and
gitlab::registry_nginx:
ssl_certificate: '/etc/gitlab/ssl/somedomain.com.crt'
ssl_certificate_key: '/etc/gitlab/ssl/somedomain.com.key'
Before I keep on digging with my local instance I need to know that it does actually work.
thanks.
I'm looking for more information on how to configure the embedded NGINX instance that comes with the GitLab Omnibus package. I can see that there's an option for providing a hash of configuration options, but I can't find anything on what options are supported and the exact data structure for the hash. My most immediate interest is configuring HTTPS.
Thanks!
To fetch packages from https sources the package apt-transport-https
must be installed on the system (at least on Debian jessie).
This module should be made compatibile with more recent version of the apt module to play nice with other module. (eg. if you "puppet module install puppetlabs-postgresql" before this you'll get an error due to an incompatible apt module being installed)
Add support for the new feature: Docker registry. See http://docs.gitlab.com/ce/administration/container_registry.html#container-registry-domain-configuration
Error: Could not enable gitlab-runsvdir: Execution of '/sbin/chkconfig --add gitlab-runsvdir' returned 1: service gitlab-runsvdir does not support chkconfig
Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]/enable: change from false to true failed: Could not enable gitlab-runsvdir: Execution of '/sbin/chkconfig --add gitlab-runsvdir' returned 1: service gitlab-runsvdir does not support chkconfig
It seems that this is enabled by default on CentOS 6, is this correct?
GitLab 8.0 introduced gitlab-workhorse(https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/README.md) for HTTP requests, so there are gitlab_workhorse[] configurations available for gitlab.rb. Would be nice if this could be managed by the module.
When using CentOS, xz-utils is incorrect. It should just be xz.
At least on RHEL, as you use a single yumrepo
resource with the same name for 2 different repos, when upgrading from CE to EE edition the Yum repo is not being updated and upgrade does not happen until you manually remove the old repo and do a yum clean
.
I think it would be enough to add edition to yumrepo
resource name but unfortunately I don't have time to create a PR right now, sorry.
@tobru I'm the author of the spuder/puppet-gitlab puppet module as mentioned here:
https://about.gitlab.com/installation/
Because of the new onibus packaging. my puppet module is currently broken.
I was planning on rewriting it, however it appears that you have already rewritten puppet gitlab to work with the new package cloud repos.
I'm evaluating if I want to deprecate my module, and instead refer people to your module. What are your thoughts on referring people to your module?
We were running spuder's gitlab module, and really want to leap to this module, but we are running puppet enterprise 3.6.2. Upgrading is on the roadmap, but not in the immediate future. Is it possible that the module is compatible with 3.6.2, but untested? Or did you use some 3.7-specific functionality (which is what I'm guessing).
Hi,
I just did a fresh install of Gitlab on RHEL 6.5 / Puppet 3.8.1 using the module, and I'm getting a 500 error when trying to access /users/sign_in (see below). I found a lot of references to this type of error for upgrades / database migrations, but less for new installations. I'm assuming that the "projects" table would be a default (since I don't have any data that I've added to gitlab yet)?
I'll keep digging, but I thought it was worth asking in case you've seen this error before after an install.
The production.log file says:
Started GET "/users/sign_in" for 127.0.0.1 at 2015-10-27 17:20:15 -0400
Processing by SessionsController#new as HTML
PG::UndefinedTable: ERROR: relation "projects" does not exist
LINE 5: WHERE a.attrelid = '"projects"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"projects"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
Completed 500 Internal Server Error in 15ms (ActiveRecord: 9.7ms)
When I tried to troubleshoot by running gitlab-ci-rake commands, it complained about not being able to load files under /opt/gitlab/etc/gitlab-ci - that directory does not appear to exist.
[root@linvm2346 gitlab-rails]# gitlab-ci-rake db:migrate:status
/usr/bin/gitlab-ci-rake error: could not load /opt/gitlab/etc/gitlab-ci/gitlab-ci-rc
Either you are not allowed to read the file, or it does not exist yet.
You can generate it with: sudo gitlab-ctl reconfigure
[root@linvm2346 gitlab-rails]# cd /opt/gitlab/etc
[root@linvm2346 etc]# ls -la
total 48
drwxrwxr-x 3 root root 4096 Oct 27 17:01 .
drwxrwxr-x 9 root root 4096 Oct 27 17:01 ..
drwx------ 3 git root 4096 Oct 27 17:01 gitlab-rails
-rw-rw-r-- 1 root root 35191 Oct 27 08:43 gitlab.rb.template
I tried running gitlab-ctl reconfigure by hand to look for errors, etc., but there weren't any obvious issues (and it still didn't create the gitlab-ci directory).
Their is an unfortunate use case scenario where one would want to install the package, repo etc, however not manage the service/config file.
So it's partially managed by puppet.
Currently, the service management by puppet is configurable however the config file management is not.
Would be useful if the config file management was optional/configurable.
since this is a private gitlab on a publicly hosted machine (out on AWS) I want SSL out of the box, so I thought I'd go with a module that will use Let's Encrypt to create my certificates. however there's a chicken and egg here - nginx won't run till I create the certs and the certs can't be created without a working webserver (that will also serve files from the disk), so unless I'm missing something...?
in order to automate this, I'd have to patch this module and make a PR. I'll happily do it on a less busy week. for now I'd love it if there's a shortcut solution that I'm missing (or I'll just manually bootstrap the first cert and fix this in June)
Thanks in advance!
Hi !
Thanks for your awesome module ! It works really nice and my only problem is how to manage Gitlab upgrade proccess ? Right now I have version 8.12.6 on my server. Version 8.13 is released and I want to upgrade my installation.
Any chance that i can do it with help of this module or should i do it manually ?
Tried to use common.yaml to put the gitlab::gitlab_rails ldap settings as described and they didn't work.
Not one value was populated into gitlab.rb
Is this still working as documented in README?
---
gitlab::gitlab_rails:
ldap_enabled: true
ldap_servers:
myldapserver:
label: 'Company LDAP'
host: 'ldap.company.tld'
port: 389
uid: 'uid'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'MYBINDDN'
password: 'MYBINDPW'
active_directory: false
allow_username_or_email_login: false
block_auto_created_users: false
base: 'MYBASEDN'
group_base: 'MYGROUPBASE'
user_filter: ''
Also can you provide detail of how to use the puppet config where hiera doesn't work to load the ldap configuration?
The way that YAML generation is done in the gitlab.rb
template runs into a big flaw when it comes to Omniauth - SAML data in particular;
A manifest like;
# ...
class { '::gitlab':
gitlab_rails => {
'omniauth_enabled' => $_saml_enabled,
'omniauth_providers' => [
{
'name' => 'saml',
'label' => '<Company ID>',
'args' => {
'allowed_clock_drift' => 5,
'assertion_customer_service_url' => "${external_url}/users/auth/saml/callback",
'idp_cert_fingerprint' => '00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10:11:12:13',
'idp_sso_target_url' => '<ADFS endpoint>',
'issuer' => $external_url,
'name_identifier_format' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
},
},
],
},
}
Will generate ruby code alike the following:
# gitlab.rb
#...
gitlab_rails["omniauth_providers"] => [
{
"args" => {
"allowed_clock_drift" => "5",
"assertion_consumer_service_url" => "<external url>/users/auth/saml/callback",
"idp_cert_fingerprint" => "00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10:11:12:13",
"idp_sso_target_url" => "<ADFS endpoint>",
"issuer" => "<external url>",
"name_identifier_format" => "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
},
"label" => "<Company ID>",
"name" => "saml"
}
]
Causing OmniAuth SAML to fail its authentication attempt when trying to use the allowed_clock_drift
string value as a numeral.
Reading into the compiled catalog reveals that Puppet is actually sending the value as a string literal. In fact, all numerals are strings in the catalog.
One possible way to prevent this could be to hard-code certain keys as guaranteed plain numerals in the template, might also not be a problem with newer Puppet versions.
Hiera Code:
gitlab::gitlab_rails:
omniauth_enabled: true
omniauth_allow_single_sign_on: false
block_auto_created_users: true
omniauth_providers:
- name: "github"
app_id: "9a6161e2354332d5b5f5"
app_secret: "ec032383e83fb59205a381f3ac9ec98a9a2bb486"
url: "https://github.com/"
args:
scope: "user:email"
The result in /etc/gitlab/gitlab.rb
gitlab_rails['omniauth_providers'] = ["{"name"=>"github", "app_id"=>"9a6161e2354332d5b5f5", "app_secret"=>"ec032383e83fb59205a381f3ac9ec98a9a2bb486", "url"=>"https://github.com/", "args"=>{"scope"=>"user:email"}}"]
The quote in the Array is not needed.
Add manifests to install and configure Gitlab CI multi runner: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
After adding an ldap_server to my gitlab hiera config every couple puppet run will trigger a reconfig. Looking into it the puppet output is shwoing a change in the gitlab.rb file. But the diff only shows a difference in the way the ldap_server hash is written to the file.
--- /etc/gitlab/gitlab.rb 2016-01-06 16:11:16.191974903 -0800
+++ /tmp/puppet-file20160106-23945-3txlqb 2016-01-06 16:20:42.223501596 -0800
@@ -21,7 +21,7 @@
gitlab_rails['gitlab_email_display_name'] = ' Gitlab'
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['ldap_enabled'] = true
-gitlab_rails['ldap_servers'] = {"myldapserver"=>{"host"=>"ldap.", "block_auto_created_users"=>false, "uid"=>"sAMAccountName", "active_directory"=>true, "label"=>"LDAP", "password"=>"", "bind_dn"=>"cn=", "base"=>"dc=", "allow_username_or_email_login"=>false, "method"=>"plain", "port"=>389}}
+gitlab_rails['ldap_servers'] = {"myldapserver"=>{"password"=>"", "block_auto_created_users"=>false, "uid"=>"sAMAccountName", "bind_dn"=>"cn=", "base"=>"dc=", "method"=>"plain", "allow_username_or_email_login"=>false, "port"=>389, "label"=>"LDAP", "host"=>"ldap.", "active_directory"=>true}}
gitlab_rails['time_zone'] = 'america/los_angeles'
*removed content, but you can see the keys are in a different order.
I believe the issue is how this is being read in vs actually merging the data because hiera works fine.
Until now I was using the deprecated spruder gitlab module ... and configuring ldap was rather simple there. can someone give me an example how to configure ldap for gitlap in the vshn module ?
thanks in advance
For Debian (instead of Ubuntu) location in init.pp is wrong
it should be
location => "https://packages.gitlab.com/gitlab/gitlab-${edition}/debian/",
reference: https://github.com/puppetlabs/puppetlabs-stdlib
and example of replacement: https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/init.pp#L17-L28
Sample dump at http://pastebin.com/v3J98Az2
Basically, the http secret, cert and internal key, plus all the mattermost salts and keys, all get removed with every puppet run and immediately new ones are generated and added by the reconfigure, which was triggered by the fact the file was edited. this seems to me like a serious bug, the entire omnibus should not need to rerun and restart on every run.
Also, does that mean mattermost is getting installed? should I be able to access it? it's not linked in the gitlab UI and I don't see any service that looks like it's related getting started.
Some strange issues with Puppet 4.5.3 and Rspec-Puppet:
Failures:
1) gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::install] that comes before gitlab::config
Failure/Error: it { is_expected.to contain_class('gitlab::install').that_comes_before('gitlab::config') }
ArgumentError:
No title provided and "gitlab::config" is not a valid resource reference
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:204:in `block in check_befores'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `each'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `check_befores'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:99:in `matches?'
# ./spec/classes/init_spec.rb:17:in `block (4 levels) in <top (required)>'
2) gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::service] that subscribes to gitlab::config
Failure/Error: it { is_expected.to contain_class('gitlab::service').that_subscribes_to('gitlab::config') }
ArgumentError:
No title provided and "gitlab::config" is not a valid resource reference
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:228:in `block in check_subscribes'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `each'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `check_subscribes'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:102:in `matches?'
# ./spec/classes/init_spec.rb:19:in `block (4 levels) in <top (required)>'
3) gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::install] that comes before gitlab::config
Failure/Error: it { is_expected.to contain_class('gitlab::install').that_comes_before('gitlab::config') }
ArgumentError:
No title provided and "gitlab::config" is not a valid resource reference
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:204:in `block in check_befores'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `each'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `check_befores'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:99:in `matches?'
# ./spec/classes/init_spec.rb:53:in `block (4 levels) in <top (required)>'
4) gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::service] that subscribes to gitlab::config
Failure/Error: it { is_expected.to contain_class('gitlab::service').that_subscribes_to('gitlab::config') }
ArgumentError:
No title provided and "gitlab::config" is not a valid resource reference
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'
# /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:228:in `block in check_subscribes'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `each'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `check_subscribes'
# /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:102:in `matches?'
# ./spec/classes/init_spec.rb:55:in `block (4 levels) in <top (required)>'
Finished in 16.74 seconds (files took 1 second to load)
44 examples, 4 failures
Failed examples:
rspec ./spec/classes/init_spec.rb:17 # gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::install] that comes before gitlab::config
rspec ./spec/classes/init_spec.rb:19 # gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::service] that subscribes to gitlab::config
rspec ./spec/classes/init_spec.rb:53 # gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::install] that comes before gitlab::config
rspec ./spec/classes/init_spec.rb:55 # gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::service] that subscribes to gitlab::config
On at least Red Hat Enterprise Linux Server release 6.7 (Santiago): The baseurl in /etc/yum.repos.d/gitlab_official.repo exands to:
https://packages.gitlab.com/gitlab/gitlab-ce/el/6Server/x86_64/repodata/repomd.xml - which is incorrect.
It should expand to:
https://packages.gitlab.com/gitlab/gitlab-ce/el/6/x86_64/repodata/repomd.xml
Tested on v1.7.0
I didn't see support for oauth configuration and backup providers in your wiki on puppetforge, if it's already supported, my apologies, but I did not find it.
It looks like a several pull requests have been merged in since the last release. Any chance a new release can be published?
After integrating CI into Gitlab there are maybe some deprecated config parameters in gitlab.rb
-> clean this up
Currently the default setting for concurrent is 4 for gitlab-runner.
There doesn't see to be a way from within the module to set it.
Because there's no template to manage, not sure of the best way to send a PR.
Thoughts?
The format of the LDAP parameters in gitlab.rb which are generated by Puppet using this module are incorrect.
Correct format as shown in the docu and the example gitlab.rb file :
( The following example is of the puppetrun deleting the right format within the original gitlab.rb: )
-# gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
-# main: # 'main' is the GitLab 'provider ID' of this LDAP server
-# label: 'LDAP'
-# host: '_your_ldap_server'
-# port: 389
-# uid: 'sAMAccountName'
-# method: 'plain' # "tls" or "ssl" or "plain"
-# bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
-# password: '_the_password_of_the_bind_user'
-# active_directory: true
-# allow_username_or_email_login: false
-# block_auto_created_users: false
-# base: ''
-# user_filter: ''
-# attributes:
-# username: ['uid', 'userid', 'sAMAccountName']
-# email: ['mail', 'email', 'userPrincipalName']
-# name: 'cn'
-# first_name: 'givenName'
-# last_name: 'sn'
-# ## EE only
-# group_base: ''
-# admin_group: ''
-# sync_ssh_keys: false
-#
-# secondary: # 'secondary' is the GitLab 'provider ID' of second LDAP server
-# label: 'LDAP'
-# host: '_your_ldap_server'
-# port: 389
-# uid: 'sAMAccountName'
-# method: 'plain' # "tls" or "ssl" or "plain"
-# bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
-# password: '_the_password_of_the_bind_user'
-# active_directory: true
-# allow_username_or_email_login: false
-# block_auto_created_users: false
-# base: ''
-# user_filter: ''
-# attributes:
-# username: ['uid', 'userid', 'sAMAccountName']
-# email: ['mail', 'email', 'userPrincipalName']
-# name: 'cn'
-# first_name: 'givenName'
-# last_name: 'sn'
-# ## EE only
-# group_base: ''
-# admin_group: ''
-# sync_ssh_keys: false
-# EOS
Wrong format as stored in gitlab.rb after the puppetrun:
+gitlab_rails['ldap_servers'] = {"active_directory"=>true, "base"=>"DC=com", "bind_dn"=>"", "host"=>"ldap.com", "label"=>"LDAP", "method"=>"plain", "password"=>"Ikwilkaas1", "port"=>389, "user_filter"=>"OU=Amsterdam,DC=com"}
Puppet should store the configuration as the
$var = YAML.load <<-'EOS'
...
var: arg
...
EOS
You seem to have two parameters, rails and gitlab_rails. I expected to use gitlab_rails, but looking at the template it uses rails. This is confusing. I expect rails should be deprecated in favour of gitlab_rails.
I didn't change the version number in the metadata.json, which means that the new additions from #76 will not propagate (especially when my local metadata.json says "version": "1.8.0-1"
:)
I'm having some issues with this module on RHEL (not CentOS, real RHEL).
This module defines the repo baseurl
as https://packages.gitlab.com/gitlab/gitlab-ce/el/$releasever/$basearch
However, on real RHEL, that evaluates as https://packages.gitlab.com/gitlab/gitlab-ce/el/7Server/x86_64/
, however https://packages.gitlab.com/gitlab/gitlab-ce/el/7Server/x86_64/repodata/repomd.xml
is 404.
It seems to me that when calculating the repository URL on RedHat-based systems, the module should probably just use the OS major release in Puppet, instead of relying on $releasever
in yum.
Hi there,
I was just wondering if this module is able to configure gitlab such that it uses SMTP for a mail server rather than postfix?
I can't see where gitlab_rails is pulling values from, I just want to be able to implement the instructions here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/smtp.md
I've tried passing the following as a gitlab_rails entry as per the readme:
{
'smtp_enable' => true,
'smtp_address' => 'mail.example.internal',
'smtp_port' => 25,
'smtp_domain' => example.net,
'gitlab_email_from' => '[email protected]',
'gitlab_email_reply_to' => '[email protected]',
},
But puppet returns that it's a string and not a hash. I don't understand why it has said that as this is the same as
{
'webhook_timeout' => 10,
'gitlab_default_theme' => 2,
},
which is in the readme.
Have I missed something?
Cheers
Alex
Excerpt from https://about.gitlab.com/2015/07/22/gitlab-7-13-released/:
GitLab CI now uses symmetric encryption to share ‘secure variables’ (provided by your users) in the SQL database. Symmetric encryption needs a secret key, which GitLab CI will generate for you when you install / upgrade to 7.13.
The key is called db_key_base and can be found in /etc/gitlab/gitlab-secrets.json (in Omnibus packages) or config/secrets.yml (in installations from source). If you lose this secret key during a backup restore or a server migration, your users will lose their ‘secure variables’.
Don’t store the secret key in the same place as your database backups. If you do, somebody who steals your backup also gets your users' secure variables.
If you use configuration management (Chef, Puppet etc.) you should store the secret key securely in your configuration management system. This way, your CI server uses the correct DB secret key after a server rebuild.
Not an error but just wanted to make note:
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: /sbin/init: unrecognized option '--version'
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: -.mount loaded active mounted /
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: gitlab Reconfigured!
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]: Triggered 'refresh' from 1 events
Add beaker acceptance tests to Travis
Basic tests to make sure standard install works 👍
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.