briantist
June 17, 2026, 3:07pm
1
I know I’ve seen documentation for this somewhere, and I just did a series of web searches with different keywords and I cannot find it anywhere.
I’m looking for how to use register projections, using _task in conditionals to avoid needing register, all of these nice features that are in core 2.21, but I can’t figure out how to find the docs anymore and I don’t remember where I saw this.
The only reference I can find now is in the Ansible 14 porting guide (the core 2.21 porting guide is just empty, even in devel )
bvitnik
June 17, 2026, 5:19pm
2
How about this?
devel ← nitzmahone:register_projections_context
opened 01:51AM - 22 Nov 25 UTC
## SUMMARY
### Register Projections
The functionality of the `register` ke… yword has been expanded to allow registration of multiple variables and inline manipulation of task output with Jinja expressions ("projections").
In addition to the existing `register: varname` form, the `register` keyword can accept a dictionary of `varname: expression` pairs (see examples below).
A new `_task` implicit variable provides Jinja expressions access to the current task's result via its `result` property. Expressions under looped tasks can also now access all completed loop results and preview the final loop task result via the `_task.loop_result` property. The new `_task` implicit variable is available to expressions in `register` and task conditionals (`changed_when`, `failed_when`, etc.). Registered variable values are updated and available to task conditional expressions as before, but task conditionals can now bypass `register` entirely by accessing `_task` directly (for tasks that do not otherwise require persistence of their result).
This functionality can simplify and declutter playbooks by allowing common patterns like "Run a task,
register the output, pick out small parts of the output with `set_fact`" to be folded directly into the task itself. Further, because the new `register` form is always a Jinja expression, template delimiters (`{{ }}`) are not required for dynamic behavior as they were with `set_fact`.
Unlike `set_fact`, variable registration expressions *can* refer to other variable expressions within the same task, and because they are evaluated lazily, can be defined in any order under `register` .
### Action APIs for creating dynamic hosts/groups/vars
A new `register_host_variables` public API method on `ActionBase` allows user action plugins to implement variable-setting functionality that was previously restricted to built-in actions or required risky use of undocumented/internal action result values.
(TBD: expand description, usage examples)
The following built-in actions have been modified to use the new API:
* `set_fact`
* `include_vars`
## REGISTER PROJECTION EXAMPLES
#### Registering multiple variables from a task
**Before register-projections**
```yml
- shell: echo hello
failed_when: echo_result.stdout is contains "goodbye"
register: echo_result
- set_fact:
echo_duration: "{{ echo_result.delta }}"
capitalized_result: "{{ echo_result.stdout | capitalize }}"
```
**After register-projections**
```yml
- shell: echo hello
failed_when: _task.result.stdout is contains "goodbye"
register:
echo_result: _task.result # The old register behavior
echo_duration: _task.result.delta
capitalized_result: _task.result.stdout | capitalize
```
#### Advanced templating and chaining variable manipulation
**Before register-projections**
```yml
- shell: echo hello
register: echo_output
- set_fact:
start_hour: "{{ echo_output.start | regex_search('\\s(\\d{2}):\\d{2}:\\d{2}', '\\1') | first | int}}"
- set_fact:
output_message: "{{ echo_output.stdout * start_hour }}"
```
**After register-projections**
```yml
- shell: echo hello
register:
output_message: _task.result.stdout * start_hour # Notice that start_hour is defined below, but can still be used! The order that they're declared does not matter.
start_hour: _task.result.start | regex_search('\\s(\\d{2}):\\d{2}:\\d{2}', '\\1') | first | int
```
#### Using `failed_when` without a register
**Before register-projections**
```yml
- shell: echo hello
failed_when: echo_result.stdout is contains "goodbye"
register: echo_result
```
**After register-projections**
```yml
- shell: echo hello
failed_when: _task.result.stdout is contains "goodbye"
```
#### Registering single loop items
**Before register-projections**
```yml
- shell: echo {{ item }}
loop:
- 1
- 2
register: echo_loop_result
- set_fact:
second_echo_stdout: "{{ echo_loop_result.results[1].stdout }}"
```
**After register-projections**
```yml
- shell: echo {{ item }}
loop:
- 1
- 2
register:
second_echo_stdout: _task.loop_results[1].stdout | default(0) # using default here is necessary as when the loop is on the first item, it will still try and access `loop_results[1]` which doesn't exist yet
```
##### ISSUE TYPE
- Feature Pull Request
And some forum discussion here also:
We’re happy to announce a new drop of the fallible experimental Ansible build, and are looking for your feedback! This one contains previews of a couple of features currently slated for release in Ansible Core 2.21:
Register Projections allows the register keyword to set multiple vars using the result of arbitrary Jinja expressions. It adds a new implicit variable (_task) for the register keyword and task conditionals (e.g., failed_when, changed_when, break_when, until) to directly access the …
oranod
June 17, 2026, 6:37pm
3
hey @briantist those docs are unmerged as yet. this was the initial PR to add them: Document register projection functionality by pkingstonxyz · Pull Request #3581 · ansible/ansible-documentation · GitHub
that was closed last week in favour of Document register projections by pkingstonxyz · Pull Request #3752 · ansible/ansible-documentation · GitHub
I’ve done a few reviews of the content and tried to help with some of the examples. I’m sure it’d be useful and well received to get some more feedback if you’d like to dip your toe into that PR…
you can find the PR preview build of those docs here too btw: Ansible Core Documentation — Ansible Core Documentation
briantist
June 17, 2026, 7:52pm
4
bvitnik:
How about this?
thank you! That might be what I saw before
Perfect thanks! Glad to see they are in progress, I’ll subscribe to that PR
Hey, I’m the author of the current docs PR. It’s been a bit slow to get reviews on that PR but it’s being worked on. Please do raise questions, concerns, comments, etc. either on the open PR Document register projections by pkingstonxyz · Pull Request #3752 · ansible/ansible-documentation · GitHub or just reply in this thread if it seems unclear/you need more examples and I’ll try and help!
briantist
June 18, 2026, 9:32pm
6
thank you! I think I’m ok with the bits of documentation I’ve seen around so I’m not looking for any new examples or anything, this came up for me when trying to tell my coworkers about it and realizing I couldn’t find anything to link to
