Sometimes it is desirable to perform a handle on some other event than 'changed'. Any opinions on the following possible playbook syntax?
- name: pull / update some repo
action: git repos=foo dest=bar version=1.3
notify:
- handler: foo-new
only_if: action_response['changed'] # << this is the default, when only_if is not defined
- handler: foo-update
only_if: action_response['version-changed'] and foo = bar # << mix in some other logic
Existing syntax would continue to be compatible. If this syntax were adopted notify could take a string (a single handler to execute on change), a dictionary (a single handler with an only_if option), or a list of strings and/or handlers.
Thoughts?
So git is only going to return a changed if the contents change, so that seems like version-changed wouldn’t exist.
OK, so 'changed' would be any change -- new clone, pull with updates,
or version= caused a change. In other words, something on the FS
changed, just as now.
Let's use 'new-clone' as an example instead of 'version-changed'.
new-clone would only be True if clone was used rather than pull...
Also... My thought was that all matching handlers would be triggered,
not just the first to match. Not sure if that was clear.
OK, so ‘changed’ would be any change – new clone, pull with updates,
or version= caused a change. In other words, something on the FS
changed, just as now.
Let’s use ‘new-clone’ as an example instead of ‘version-changed’.
new-clone would only be True if clone was used rather than pull…
what’s the real world example of your setup that should only be run on an update not an initial install?
there may be other solutions and the end goal should be to make things reasonably idempotent, so there
might be another solution
hard to say without seeing a real-world playbook excerpt, sans ‘foo’
The real world example is actually the other way around. In my case,
it has to do with a setup script that should be run if git does a
clone (new install) but not if it does a pull. Now that I think about
it, though, the way I'm doing it is better... check whether a file
that the setup creates exists. While it might be 'cleaner' to do it
with an only_if statement, it could cause unpredictable results if,
for example, the former run of the playbook had failed after cloning
but before running setup.
I'll let you know if I encounter another situation where this might be
handy. Until then, I won't mention it further.
Offhand, this sounds like an excellent case for RPM packaging vs using the git module, where the difference between an install and upgrade is detectable, and the package can handle the post scriptlets.
I’m not sure about dpkg but would presume it can do similar.
–Michael