Closed maxenced closed 5 years ago
So, after this happened again I checked the log / code, so here is what happens :
which simply drop & recreate the environment directory: https://github.com/xorpaul/g10k/blob/a4554d72c36a4e5f398376f73e1c893c76c3d1e2/helper.go#L144 https://github.com/xorpaul/g10k/blob/a4554d72c36a4e5f398376f73e1c893c76c3d1e2/helper.go#L148
So at this point we have no more environment. We then go through preparePuppetFile()
, readPuppetfile()
and resolvePuppetfile()
. Here, because the -module
option is use, only 1 module is setup, others are ignored.
So, for me, the issue is that https://github.com/xorpaul/g10k/blob/d9d50df1ad60c6da91b15d48a75c308363e453c5/git.go#L170 should not be called here
The problem is that g10k can't be sure what changed inside the control / environment repository. Was a file removed or modified or added?
The easiest way to archive a "clean" environment is to simply delete the environment directory and repopulate it again, which is what I did chose while developing g10k at the beginning.
I don't know how r10k tracks the control / environment repository changes, so that it detects that it only needs to resync one module. I'll have a look at the r10k code.
You're talking about using the -module
parameter, but I don't see that parameter in the original post. Can you please clarify what you mean with:
Here, because the -module option is use, only 1 module is setup, others are ignored.
You're talking about using the
-module
parameter, but I don't see that parameter in the original post.
Oh ... you're right, forgot it in the first copy / paste it seems. Fixed the original post. AFAIK r10k does a diff between the modules currently existing on filesystem and the Puppetfile, and remove the deleted modules.
I'm fine with the delete & recreate, but then a full environment deployment should be forced, no matter if -module
is specified or not (I think).
any news on this issue ? As we create a lot of environments it would be really useful to at least ignore the -branch when a change is detected in puppetfile repo :)
any news on this issue ? As we create a lot of environments it would be really useful to at least ignore the -branch when a change is detected in puppetfile repo :)
You mean ignore the -module
parameter?
As I understand it you would be fine with purging and recreating/populating the complete Puppet environment, but your whole problem is that the -module
parameter then only populates the control/Puppetfile repository with that specified Puppet module. Is this correct?
In the long-term I definitely want to emulate the r10k behavior for control/Puppetfile repository changes, but simply ignoring the -module
parameter would be something, which I could provide you with much faster.
yeah sorry, -module
is the correct thing. Agree with emulating r10k behavior in long term, but at least ignoring -module
when puppetfile repo changes would make g10k more consistent and should be much easier to implement.
Okay, I've implemented the purge_levels from r10k and stopped purging the whole Puppet environment directory if the control repository was changed.
Please test https://github.com/xorpaul/g10k/releases/tag/v0.7.0
We are switching to g10k for some big environment (380 modules per env, ~ 10 env).
It seems to work quite well, except for a thing. When we push some modifications on one of the 380 modules, we trigger a run of :+1:
/usr/local/bin/g10k -config /etc/g10k.yaml -branch production -maxworker 2 -retrygitcommands -maxextractworker 2 -module somemodule
This works correctly, except if we modified the repository which contains the Puppetfile (even if we do not modify the Puppetfile itself) before.
In that case, g10k seems to detect the main (ie the Puppetfile) repository has changed, which is good, but it then delete all the modules from environment, before updating the one we just modified.
g10k.conf is simple :