implicit cast '1' to integer 1 in ruby template

[shcherbak]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.3
• Ruby: ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]
• Distribution: Debian GNU/Linux 9
• Module version: 2.1.0

How to reproduce (e.g Puppet code you use)

hiera.yaml:
gitlab::gitlab_rails:
env:
BUNDLE_GEMFILE: '/opt/gitlab/embedded/service/gitlab-rails/Gemfile'
PATH: '/opt/gitlab/bin:/opt/gitlab/embedded/bin:/bin:/usr/bin'
SIDEKIQ_LOG_ARGUMENTS: '1'

What are you seeing

value must be nill or string, you passed 1

What behaviour did you expect instead

gitlab_rails['env'] = {
"BUNDLE_GEMFILE" => "/opt/gitlab/embedded/service/gitlab-rails/Gemfile",
"PATH" => "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/bin:/usr/bin",
"SIDEKIQ_LOG_ARGUMENTS" =>1
}
but shuold be ("SIDEKIQ_LOG_ARGUMENTS" =>'1' ) :
gitlab_rails['env'] = {
"BUNDLE_GEMFILE" => "/opt/gitlab/embedded/service/gitlab-rails/Gemfile",
"PATH" => "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/bin:/usr/bin",
"SIDEKIQ_LOG_ARGUMENTS" =>'1'
}

Output log

Any additional information you'd like to impart

[LongLiveCHIEF]

Ouch. This one might wind up on the "will not fix" category. This isn't a recommended/officially supported setting for the omnibus template, and is a development setting only.

What you can do though, is add a file {'/opt/gitlab/etc/gitlab-rails/env/SIDEKIQ_LOG_ARGUMENTS': } resource yourself in the same manifest you call class {'gitlab':} from. (setting gitlab_rail['env'] = {"SIDEKIQ_LOG_ARGUMENTS"=>"1"} actually does nothing more than create this file and set it's content to 1`)

Make sure that resource notifies the Service['gitlab-runsvdir'] so that gitlab will restart rails with the environment process variables correctly after setting this up.

The next release actually will have a built-in way to order this stuff correctly so you don't even need to issue a restart manually.

We might actually pivot this into a feature request for "development mode settings" that you can inject in-between the config and service phases of the module so it will handle restart properly.

For the moment though, you'll have to do it like this:

class {'gitlab':
  ...
}

file {'/opt/gitlab/etc/gitlab-rails/env/SIDEKIQ_LOG_ARGUMENTS:
  ensure => 'present',
  mode => '0644',
  owner => 'root',
  group => 'root',
  content => "1",
  require => Class['sfgitlab'],
  notify => Service['gitlab-runsvdir']
}

[LongLiveCHIEF]

@voxpupuli/collaborators I haven't labeled this yet, because I haven't decided if it's wont-fix, needs-docs, or enhancement, depending on where things land closer to the v3.0.0 release.

Technically the v3 release already has support for ordering these types of things, in conjunction with the new service_provider_restart => true parameter, but it may need either some tags or some sort of hook before I can say it's fully supported.

[shcherbak]

Thanks a million

[LongLiveCHIEF]

@shcherbak if you just now looked at this, i edited the comment I made to indicate the content => "1" attribute of that file. Wanted to make sure you caught that.

[LongLiveCHIEF]

and I messed up the file path, which i also just fixed. 🤦 . It's a monday.