prefix of "repo" does not seem to apply

[damonmaria]

Looking at the code for the GetPrefix function, it would appear that setting the prefix in configuration to "repo" would prefix the environment with the repo name. This is exactly what we need (we manage many different repos with the one server).

But when I try that in production I can see the environment name the webhook has built is repo_production. I also can't see GetPrefix being used (apart from in tests) in the codebase.

Using the repo name as a prefix would be a workable solution for us until #115 comes along. Can this feature (as I'm guessing it's supposed to work) be enabled?

[bastelfreak]

Hey, can you show your r10k config file? It has an option to set the prefix.

[damonmaria]

Hey, can you show your r10k config file? It has an option to set the prefix.

That is setup in r10k.yaml. See below.

---
pool_size: 4
git:
  provider: shellgit
deploy:
  purge_levels:
  - deployment
  - environment
  - puppetfile
  generate_types: true
cachedir: "/opt/puppetlabs/puppet/cache/r10k"
sources:
  devops:
    remote: git@github.com:*******/devops-control.git
    basedir: "/etc/puppetlabs/code/environments"
    prefix: true
  foo:
    remote: git@github.com::*******/:foo-control.git
    basedir: "/etc/puppetlabs/code/environments"
    prefix: true
...

But when webhook-go tries to call r10k it is not prefixing the environment it calls with. Here's from the logs of the webhook-go.service:

failed to execute local command `[/opt/puppetlabs/puppet/bin/r10k deploy environment production --config=/etc/puppetlabs/r10k/r10k.yaml --verbose --generate-types --modules]` 
with error: `exit status 1` 
`ERROR	 -> Environment(s) 'production' cannot be found in any source and will not be deployed.`

Note the passed environment is production without a prefix.

After seeing the code in Helpers.GetPrefix I had thought setting the r10k/prefix in /etc/voxpupuli/webhook.yml to prefix: 'repo' would have changed this failed call to call with an environment based on the repo name, something like (from my example above) devops_control_production. But instead I got:

failed to execute local command `[/opt/puppetlabs/puppet/bin/r10k deploy environment repo_production --config=/etc/puppetlabs/r10k/r10k.yaml --verbose --generate-types --modules]` 
with error: `exit status 1` 
`ERROR -> Environment(s) 'repo_production' cannot be found in any source and will not be deployed.`

Am I doing something incorrectly?

[damonmaria]

For completeness, this is our webhook.yaml:

---
server:
  protected: true
  user: puppet
  password: puppet
  port: 21947
  tls:
    enabled: true
    certificate: "/etc/puppetlabs/puppet/ssl/certs/puppet.mindhive.cloud.pem"
    key: "/etc/puppetlabs/puppet/ssl/private_keys/puppet.mindhive.cloud.pem"
  queue:
    enabled: false
    max_concurrent_jobs:
    max_history_items:
chatops:
  enabled: false
  service:
  channel:
  user:
  auth_token:
  server_uri:
r10k:
  command_path: "/opt/puppetlabs/puppet/bin/r10k"
  config_path: "/etc/puppetlabs/r10k/r10k.yaml"
  default_branch: production
  prefix:
  allow_uppercase: false
  verbose: true
  deploy_modules: true
  generate_types: true

[damonmaria]

Looking over how the cmd in environment.go is built, the environment passed to r10k is calculated here as:
h.GetEnvironment(branch, conf.R10k.Prefix, conf.R10k.AllowUppercase)

If the prefix (conf.R10k.Prefix) in that call was replaced with h.GetPrefix(data, conf.R10k.Prefix) then setting the prefix in webhook.yaml to "repo" would enable this functionality. I'm guessing that is the intention of Helper.GetPrefix?

For our situation it would be best to have an option in webhook-go to use the sources in r10k.yaml to figure out the 'source' name and use that as the prefix, but the above is a much easier fix.

Does that make sense?

[chriscn]

@damonmaria I've fixed this in my PR #202

[damonmaria]

@damonmaria I've fixed this in my PR #202

That is precisely what we really want. Would love for this to be merged. Nice work.

[dhollinger]

This issue was fixed by pr #202