Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

always in block isn't triggered after failure of task from include #15623

Closed
rudimeyer opened this issue Apr 27, 2016 · 4 comments
Closed

always in block isn't triggered after failure of task from include #15623

rudimeyer opened this issue Apr 27, 2016 · 4 comments
Assignees
@jimi-c
Labels
bug This issue/PR relates to a bug.

Comments

@rudimeyer
Copy link
Contributor

rudimeyer commented Apr 27, 2016 •
edited

ISSUE TYPE
  • Bug Report
ANSIBLE VERSION
  • ansible 2.0.2.0
  • ansible 2.1.0.0 (detached HEAD 5954a82)
  • ansible 2.2.0 (devel 6b0710d)
CONFIGURATION
OS / ENVIRONMENT

N/A

SUMMARY

When task in included task-file in role fails, 'always' part of block is not run.

STEPS TO REPRODUCE
roles/test_role/tasks/main.yml:

---
- block:
    - name: This task succeeds
      command: /bin/true
    - include: "include_file.yml"
  always:
    - name: This should always execute
      debug: msg="This should always execute"

include_file.yml:

---
- name: "This task fails"
  command: /bin/false

playbook:

---
- hosts: all
  roles:
    - test_role
EXPECTED RESULTS

After failed task in included file, 'always' part of the block should be run before play is terminated

ACTUAL RESULTS

When task in included file fails the play is stopped without going through the 'always' part of the block.

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [host]

TASK [test_role : This task succeeds] ******************************************
changed: [host]

TASK [test_role : This task fails] *********************************************
fatal: [host]: FAILED! => {"changed": true, "cmd": ["/bin/false"], "delta": "0:00:00.008951", "end": "2016-04-27 12:44:34.913664", "failed": true, "rc": 1, "start": "2016-04-27 12:44:34.904713", "stderr": "", "stdout": "", "stdout_lines": [], "warnings": []}
    to retry, use: --limit @test.retry

PLAY RECAP *********************************************************************
host          : ok=2    changed=1    unreachable=0    failed=1
@abadger
Copy link
Contributor

abadger commented Apr 27, 2016

/cc @jimi-c possible dynamic includes issue?

@jimi-c jimi-c self-assigned this Apr 27, 2016
jimi-c added a commit that referenced this issue Apr 29, 2016
@jimi-c
Fixing bugs in strategies
67e7730 
* Don't filter hosts remaining based on their failed state. Instead rely
  on the PlayIterator to return None/ITERATING_COMPLETE when the host is
  failed.
* In the free strategy, make sure we wait outside the host loop for all
  pending results to be processed.
* Use the internal _set_failed_state() instead of manually setting things
  when a failed child state is hit

Fixes #15623
@jimi-c
Copy link
Member

jimi-c commented Apr 29, 2016

@rudimeyer the above patch resolves the issue for me (as well as fixing at least one other issue I found during testing). If you could also do some testing with any real-world playbooks you might have I'd appreciate it.

@jimi-c
Copy link
Member

jimi-c commented May 3, 2016

@rudimeyer (or anyone else): have you had any chance to confirm whether this patch/feature branch works for you?

jimi-c added a commit that referenced this issue May 6, 2016
@jimi-c
Fixing bugs in strategies
506e625 
* Don't filter hosts remaining based on their failed state. Instead rely
  on the PlayIterator to return None/ITERATING_COMPLETE when the host is
  failed.
* In the free strategy, make sure we wait outside the host loop for all
  pending results to be processed.
* Use the internal _set_failed_state() instead of manually setting things
  when a failed child state is hit

Fixes #15623
@jimi-c jimi-c closed this as completed in 09c90f7 May 6, 2016
@jimi-c
Copy link
Member

jimi-c commented May 6, 2016

As there has been no feedback, I've gone ahead and merged this in, as it fixes the reported issue. This will also be included in the next release.

If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@jimi-c jimi-c

Labels
bug This issue/PR relates to a bug.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jimi-c @abadger @ansibot @rudimeyer