Pass changed modules list into the postrun command

[tparkercbn]

Duplicate of #660 that was closed inactive.

Use Case

I pull my environments every 5 minutes and use a postrun command to flush the cache. This seems buggy and puppet runs fail as the cache is being reloaded due to missing modules.

Describe the Solution You Would Like

I would like to have a list of the modules that changed on the run so that I can decided to flush the cache (or do anything else really) based on either the number of modules changed or a specific trigger.

Describe Alternatives You've Considered

None.

Additional Context

N/A

[ncstate-mafields]

In my opinion, switching to a webhook based workflow instead of a regular cronjob is a better solution for what you're looking for. Having r10k only run when there are changes to the control repo means that every time r10k runs there is something that did change. You can then use the $modifiedenvs value passed to the postrun script for the script to know which environments need to be reloaded, and only reload those environments.

[tparkercbn]

I agree that webhooks is 100% the way to go however there are lots of ocasions where I have a module change that is defined in my control repo as 'main' that needs to trigger a pull on r10k but that doesn't always trigger a change to the control repo... Is there a list of environment variables documented somewhere that are passed to the postrun script? (I'm going to grep the source now that you have provided me with one)

[ncstate-mafields]

Nothing is passed into the script by default, so you have to explicitly define it as an argument in the config file.

postrun: ['/usr/local/bin/r10k-postrun', '$modifiedenvs']

The only reference to it I've found in the docs has been here: https://github.com/puppetlabs/r10k/blob/28232fa24f04925af666f3dc603df5bcbfdb2bc7/doc/dynamic-environments/configuration.mkd

[nabertrand]

I agree that webhooks is 100% the way to go however there are lots of ocasions where I have a module change that is defined in my control repo as 'main' that needs to trigger a pull on r10k but that doesn't always trigger a change to the control repo...

In this case, you could still use a webhook that triggers a different command to run, e.g.

r10k deploy module main

This causes all environments that have the module main to pull in the change. I believe you can then additionally use the $modifiedenvs variable with a postrun script to trigger reloads, etc.

[ncstate-mafields]

Yes, we use the webhook functionality provided by the voxpupili r10k puppet module, which has two endpoints: one for control-repositories which will deploy environments, and one for modules which will deploy the module.

https://github.com/voxpupuli/puppet-r10k/blob/master/templates/webhook.bin.erb

[binford2k]

Closing, as the webhook functionality appears to be a better approach.