Where is the documentation for register projections and "_task"?

bvitnik · June 17, 2026, 5:19pm

How about this?

github.com/ansible/ansible

Register projections and action plugin dynamic host/group/var API (#86241)

devel ← nitzmahone:register_projections_context

opened 01:51AM - 22 Nov 25 UTC

nitzmahone

+3809 -2584

## 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:

Topic		Replies	Views
Fallible 2025.12.5 released with Register Projections and new Action API previews News & Announcements	9	453	December 9, 2025
register expressions Ansible Project	0	22	December 26, 2012
features of register: Ansible Project	3	29	November 23, 2013
[WARNING]: "register" is not templatable, but we found: Ansible Project	4	149	April 22, 2020
Conditional register not working Ansible Project	5	77	August 8, 2014

Where is the documentation for register projections and "_task"?

Related topics