xorpaul/g10k

Weird behavior of -environment and -branch

Closed this issue · 3 comments

cedriclaudrel commented

Before v0.7.1 (and before that, with r10k), we used -branch to target a "fully qualified" environment name, for example foo_master to update the master branch of the foo repository.

Since 143ea1e , -branch doesn't work like that anymore.

Here is my test config file :

# cat /root/g10k_test.yaml
---
:cachedir: '/data/g10k/cache'

sources:
  foo:
    remote: 'https://github.com/xorpaul/g10k-environment.git'
    basedir: /data/puppetserver/environments
    prefix: true
  bar:
    remote: 'https://github.com/xorpaul/g10k-environment.git'
    basedir: /data/puppetserver/environments
    prefix: true

With g10k v0.7.0 :

# /usr/local/bin/g10k -config /root/g10k_test.yaml -branch foo_master
Resolving Git modules (4/4)    1s [====================================================================] 100%
Resolving Forge modules (6/6)    1s [====================================================================] 100%
Synced /root/g10k_test.yaml with branch foo_master with 5 git repositories and 6 Forge modules in 3.7s with git (2.7s sync, I/O 0.4s) and Forge (2.4s query+download, I/O 3.2s) using 50 resolv and 20 extract workers

It works fine, and if I do the same with bar_master, it deploys the other environment next to the first one, as expected.

With g10k v0.7.2 :

# ./g10k -config /root/g10k_test.yaml -branch foo_master
Synced /root/g10k_test.yaml with branch foo_master with 0 git repositories and 0 Forge modules in 0.9s with git (0.0s sync, I/O 0.0s) and Forge (0.0s query+download, I/O 0.0s) using 50 resolv and 20 extract workers

It doesn't deploy anything, so it seems that we have a regression (at least a breaking change) here.

If I only specify master, it runs by deploying the master branch from all environments (this doesn't suit our workflow) :

./g10k -config /root/g10k_test.yaml -branch master
Resolving Git modules (4/4)    0s [====================================================================] 100%
Resolving Forge modules (6/6)    0s [====================================================================] 100%
Synced /root/g10k_test.yaml with branch master with 10 git repositories and 12 Forge modules in 1.6s with git (0.8s sync, I/O 0.5s) and Forge (0.0s query+download, I/O 0.0s) using 50 resolv and 20 extract workers

If I try to emulate the previous behavior using the new -environment flag, things get weirder :

# ./g10k -config /root/g10k_test.yaml -environment foo_master 
WARNING: Environment 'bar_' cannot be found in any source and will not be deployed.
Resolving Git modules (4/4)    1s [====================================================================] 100%
Resolving Forge modules (6/6)    1s [====================================================================] 100%
Synced /root/g10k_test.yaml with 5 git repositories and 6 Forge modules in 3.9s with git (2.9s sync, I/O 0.5s) and Forge (2.3s query+download, I/O 3.2s) using 50 resolv and 20 extract workers

foo_master is correctly deployed, but it seems like g10k is looking for other environments with an ending underscore : Environment 'bar_' cannot be found.

Same thing if I try to deploy the other env :

# ./g10k -config /root/g10k_test.yaml -environment bar_master 
WARNING: Environment 'foo_' cannot be found in any source and will not be deployed.
Resolving Git modules (4/4)    0s [====================================================================] 100%
Resolving Forge modules (6/6)    0s [====================================================================] 100%
Synced /root/g10k_test.yaml with 5 git repositories and 6 Forge modules in 1.4s with git (0.8s sync, I/O 0.5s) and Forge (0.0s query+download, I/O 0.5s) using 50 resolv and 20 extract workers

This time, bar_master has been correctly deployed, but since foo hasn't been found, the previous deployment has been purged from basedir.

Let me know if I do something wrong here, I'd happily test some fixes/workaround if needed :)

xorpaul commented

My bad, thanks for catching that.

You're right to use the -environment parameter now if you only want to deploy only a specific Puppet environment.

I've removed the unnecessary warning and skipped the wrong removal of Puppet environments if -environment was specified.

I'm preparing a release for that bug fix.

  • 👍1
cedriclaudrel commented

Yeah 👍

I'll let you know if it's better with this new release :)