-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Whole g10k run stops on a single broken branch #57
Comments
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. |
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... |
Any ideas for more reasonable workaround? Without solving this some way we can't start using g10k. :( |
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 I'll update this if I have something to test for you. |
Please test https://github.com/xorpaul/g10k/releases/tag/v0.3.5
If you then call g10k with that config file and at least the info verbosity level, you should get something like:
|
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. |
Looks like it works as intended. |
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:
But I guess that some people may prefer this to be configurable - skip or fail.
(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.
The text was updated successfully, but these errors were encountered: