On Mon, 04 Jul 2016 00:10:58 -0000 "Will Thames" <willthames@xxxxxxxxxxxxxxxxx> 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/rules/GitHasVersionRule.py Cool. Yep. kevin
Attachment:
pgpvJwA2Q0c4h.pgp
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
