Whole g10k run stops on a single broken branch

[gdubicki]

I have ~40 environments with Puppetfiles that I want to deploy with g10k.

But among those environments there are a few with Puppetfiles, which reference branches of some modules, which do not exist anymore.

In this case whole g10k run fails on this env.

I have two problems here:

1. I would prefer g10k to just skip broken modules and just notify me at the end of the run about problems per each environments.

But I guess that some people may prefer this to be configurable - skip or fail.

2. If I don't enable verbose mode I can't tell in which environment there is the reference to nonexistent branch as the output looks like this:

Resolving Git modules (117/117) 8.204s [====================================================================] 100%
Resolving Forge modules (103/103) 744ms [====================================================================] 100%
2017/05/11 20:31:42 executeCommand(): git command failed: git --git-dir /var/cache/g10k/modules/git@git.company.com-group_roles.git rev-parse --verify 'OPS_13195' exit status 128
Output: fatal: Needed a single revision

If you are using GitLab be sure that you added your deploy key to your repository

(I am using GitLab but of course the deploy key is in that repo - OPS_13195 branch isn't)

If I do enable verbose it gets better if the problem was in non-first module in the environment, but if it would be in the first one then I would be out of luck.

[xorpaul]

Yeah g10k failing completely if one environment branch is broken is definitely an intended feature.

But making this configurable in the g10k config and as a cli parameter could be an acceptable solution.

I do have an internal ticket open to add the causing environment/Puppetfile to the error message, but hadn't had the time to resolve it.

[gdubicki]

That's sad. I tried running g10k for each branch separately, in a loop as a workaround, but that makes you loose the performance benefits of using g10k instead of r10k...

[gdubicki]

Any ideas for more reasonable workaround? Without solving this some way we can't start using g10k. :(

[xorpaul]

As I've said in the first comment a toggle in the g10k config and as a cli parameter should be an acceptable solution.

And given that I already support the :ignore-unreachable Git module attribute, adding a global setting for this shouldn't be that difficult.

I'll update this if I have something to test for you.

[xorpaul]

Please test https://github.com/xorpaul/g10k/releases/tag/v0.3.5
Using the new ignore_unreachable_modules g10k config setting.

---
:cachedir: '/tmp/g10k'
ignore_unreachable_modules: true

sources:
  example:
    remote: 'https://github.com/xorpaul/g10k-failing-env.git'
    basedir: '/tmp/failing/'

If you then call g10k with that config file and at least the info verbosity level, you should get something like:

Failed to populate module /tmp/failing/master/modules//sensu/ but ignore-unreachable is set. Continuing...

[gdubicki]

Thank you for a quick fix! I have tested a run without any verbosity and it did pass. :) I will test further and let you know.

[xorpaul]

Looks like it works as intended.