You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the restic_backups object is a dictionary, everything after (BACKUP) reformat dict if necessary gets skipped. If you instead use an array it works fine.
After some investigation, I think it's to do with how the aforementioned task works. After placing a debug task just after it, it appears that restic_backups isn't transformed as wanted (i.e. it's the same dict). This isn't because of the jinja expression - I'm using that to transform my dict at role invocation => it does what we want.
I recall reading somewhere that you can't set a fact on top of itself - if thats indeed the case then the fix is to edit that task such that it sets the new fact as a different name.
The text was updated successfully, but these errors were encountered:
Another thought - looking at this SO thread answer it may actually be to do with variable precedence.
Since set_facts output has a low precedence, we end up not overriding it as we expect. The workaround is the same: change the name of the new fact
@usmanatron Please share the Ansible version you experienced this with, and provide a playbook which reproduces it. See #122 for an example.
Also, test with the most recent version of this role. Before, there was a dependency on jmespath for this reformatting, but that dependency was just removed.
When the restic_backups object is a dictionary, everything after
(BACKUP) reformat dict if necessary
gets skipped. If you instead use an array it works fine.After some investigation, I think it's to do with how the aforementioned task works. After placing a debug task just after it, it appears that
restic_backups
isn't transformed as wanted (i.e. it's the same dict). This isn't because of the jinja expression - I'm using that to transform my dict at role invocation => it does what we want.I recall reading somewhere that you can't set a fact on top of itself - if thats indeed the case then the fix is to edit that task such that it sets the new fact as a different name.
The text was updated successfully, but these errors were encountered: