Sanitize debug var= tasks of the loop variable

[AlanCoding]

SUMMARY

Proposed fix for #65856

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

debug

ADDITIONAL INFORMATION

I have a test case for this, modeled after

ansible/test/integration/targets/loop_control/runme.sh

Line 10 in 495c197

[ "$(ansible-playbook label.yml "$@" |grep 'item='|sed -e 's/^.*(item=looped_var \(.*\)).*$/\1/')" == "${MATCH}" ]

./runme.sh

(you have to manually inspect the exit code in that case)

inside runme.sh

[ "$(ansible-playbook -i localhost, loop_test.yml | grep 'value2')" == "" ]

inside loop_test.yml

- name: loop_control/debug
  hosts: localhost
  gather_facts: false
  connection: local
  vars:
    my_var: foo
    loop_me:
      - attr1: value1
        attr2: value2
  tasks:

    - name: Echo a var inside of a loop, should only print the label value1
      debug: var=my_var
      loop: "{{ loop_me }}"
      loop_control:
        label: "{{ foo_bar.attr1 }}"
        loop_var: "foo_bar"

    - name: Echo text inside of a loop, should not print anything in loop_me
      debug: msg='hello'
      loop: "{{ loop_me }}"
      loop_control:
        label: "{{ foo_bar.attr1 }}"
        loop_var: "foo_bar"

I am less confident about integrating this into the tests, although there really shouldn't be a problem with it.

and I confirm exit code 1 with devel and exit code 0 with this patch.

[mkrizek]

We might want to do the same for ansible_index_var variable too.

[AlanCoding]

good call, added that to the test playbook and found it show up. Pushing change now.

[bcoca]

actually, any var that is not the 'item' in vars= should be removed

[AlanCoding]

I found that this afflicts Ansible 2.9 as well, since it's a bug fix, I'm going to add the changelog

[mattclay]

/azp run

[azure-pipelines]

No commit pushedDate could be found for PR 66269 in repo ansible/ansible

[mattclay]

This PR needs to be rebased before CI can run.

[webknjaz]

@mattclay that ci_verified label doesn't exclude PRs from the “stuck” queue, FYI.

[mattclay]

/azp run

[azure-pipelines]

No commit pushedDate could be found for PR 66269 in repo ansible/ansible

[mattclay]

After seeing the No commit pushedDate error on another PR, where one /azp run comment failed and a second one passed, I figured I'd try again. Looking at the GH API output for https://api.github.com/repos/ansible/ansible/pulls/66269 I see pushed_at dates -- I don't know if that's the same as what AZP is looking for when it's looking for pushedDate.

[mattclay]

I'll try closing and re-opening to see if that changes things.

[mattclay]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mattclay]

That seems to have worked. So perhaps the No commit pushedDate error is due to something on the GH side of things.

[mattclay]

@mattclay that ci_verified label doesn't exclude PRs from the “stuck” queue, FYI.

Yeah, I wanted to see if the new bot would remove the label or not. If not, I was thinking we might want to update our search filter to exclude ci_verified when searching for needs_ci -- but now it seems that may not be necessary. I'm going to try updating the other PRs with a close/re-open as well to see if they'll report results.

This PR still needs a rebase to have a chance at passing CI. That's no longer due to the No commit pushedDate error, but because it's old enough that the shallow clone we're doing isn't finding the merge base.

[webknjaz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[webknjaz]

@AlanCoding could you rebase?