On Mon, 04 Jul 2016 00:10:58 -0000
"Will Thames" <willthames(a)fedoraproject.org> wrote:
> Greetings.
Hello, I've signed up to respond to this thread, I hope that's ok.
I'll send an introductory email later.
You bet! :)
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 module).
But if there are new commits it will show changed no?
Having said that, if you seek repeatability you need to solve this
problem either way
Yep.
> 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
> dislike 4.
The only way you'll have new infrastructure be consistent with
existing infrastructure is 2. It's more work, but it's more correct.
Agreed. This would be somewhat of a burden on the QA folks... hopefully
I can get them to chime in if it would be too much of a burden.
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.
https://github.com/willthames/ansible-lint/blob/master/lib/ansiblelint/ru...
Cool. Yep.
kevin