Hello, I've signed up to respond to this thread, I hope that's ok.
I'll send an introductory email later.
In my continuing quest to get our daily ansible check/diff report to
0 and all playbooks to be idempotent I have run into a case I would
like to ask everyone about. :)
The ansible git module is in use in a number of playbooks/roles now. By
default (or if you specify update=yes) it will do a git pull to pull
the latest changes, so it's not idempotent (ie, when running --check it
always shows such tasks as changed because it cannot know if there's
going to be new data or not)
That's not my reading of the git module (it checks to see if remote head
is the same as current head before fetching - changed should be False,
even in check mode, if there are no new commits. I haven't tested if this
is actually the behaviour, but if not, it sounds like that's a bug in the git
Having said that, if you seek repeatability you need to solve this problem
There's a number of ways we could handle this:
1. Set all git: module usage to have 'update=no'.
2. Set all git: module usage to use 'version=SHA-1'.
3. Set all git: module usage to have 'changed_when: False' so they
would never show as changed.
4. Set all git: modules to when: not ansible_check_mode
5. Weed out these git changes from our reports so they still are
changed, but don't annoy me.
Personally, I am torn between 1 and 2 and dislike 3 and 4 and really
The only way you'll have new infrastructure be consistent with existing
infrastructure is 2. It's more work, but it's more correct.
As you say, the problem with 1 is that old infrastructure will be pinned to
whatever version it gets built with, and new infrastructure may well receive
a later commit.
3 and 4 are just ways of making ansible misreport the truth.
5 is simply ignoring the problem - and you're right that it's an actual problem.
One of the ansible-lint rules is designed to encourage the use of 2.