Save value of json_query as real integer (without quotes) rather than as string

Archives Ansible Project
1

Hi there,

Currently I try to fetch an integer value of an API and to use that exact value later on to create an object via the same API. The problem is, the API only accepts JSON numbers (integer in this case) as input. Is there any way to tell Ansible to save a value as a “true” integer without the brackets?

My tasks:

`

  • name: Foo
    hosts: all
    tasks:

  • name: Get the JSON object
    uri:
    url: https://jira.foo.bar/rest/agile/1.0/board/219/sprint?state=active
    user: “{{ username }}”
    password: “{{ password }}”
    force_basic_auth: yes
    body_format: json
    register: response
    delegate_to: localhost

  • name: Show important part of response
    debug:
    msg: “{{ response.json }}”

  • name: Try to filter out ID without brackets
    debug:

msg: “{{ response.json |json_query(‘values[0].id’) |int }}”

msg: “{{ response.json |json_query(‘values[0].id’) }}”

msg: “{{ response.json |json_query(‘values[0].id’) | to_json }}”

msg: “{{ response.json |json_query(‘values[0].id’) | to_json |int }}”

msg: “{{ response.json |json_query(‘values[0].id’) | int | to_json }}”

`

This is the output of the first debug task where values[0].id is 341

TASK [Show important part of response] **************************************************************************************************************************************************************************************************************************************** ok: [test] => { "msg": { "isLast": true, "maxResults": 50, "startAt": 0, "values": [ { "endDate": "2019-07-22T12:00:00.000+02:00", "goal": "", "id": 341, "name": "2019 KW 29", "originBoardId": 1, "self": "https://jira.foo.bar/rest/agile/1.0/sprint/341", "startDate": "2019-07-15T12:00:21.585+02:00", "state": "active" } ] } }

This is the output of any try of the second debug task, values[0].id is every time “341”

TASK [Try to filter out ID without brackets] ********************************************************************************************************************************************************************************************************************************** ok: [test] => { "msg": "341" }

But the API doesn’t accept a value of “341”, it needs a JSON number instead of a string.

Is there anything I can do to achieve that?

Best regards,
Hauke

2

Don't filter it through to_json, following debugs will show that the value is a int

- debug: msg={{ response.json.values.0.id | type_debug }}
- debug: msg={{ response.json | json_query('values[0].id') | type_debug }}

3

Hi Kai,

that’s interesting. It really is an integer, but how can I achieve it to print it like that?

For instance something like

`

  • name: Foo
    hosts: all
    vars:
    test_int: 100
    tasks:
  • name: Print test_int
    debug:
    msg: “{{ test_int }}”

`

prints the value without brackets. So I guess it should be possible in general to just print numbers without any brackets.

TASK [Print test_int] *********************************************************************************************************************************************************************************************************** ok: [test] => { "msg": 100 }

Best regards,
Hauke

4

For dedicated use cases/playbook I tend to set ANSIBLE_JINJA2_NATIVE to true:

https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-jinja2-native

But setting that globally in ansible.cfg had some unintended side
effect, as up to now a lot of ansible code (roles modules etc) had
been coded towards the old behaviour.
In short, YMMV.

Dick

5

When using the variables Ansible/Jinja will mostly do the right thing.

Screen output is just for informational purposes to the user and is heavy formatted by the callback plugin[1].
The default callback plugin is call default and have quotes everywhere.
But there are many[2] to choose from and some is better than other to print information on screen.

Personally I use the debug[3] one since it gives a more human readable output and it's very verbose so any error will have all the information I need.

[1] https://docs.ansible.com/ansible/2.8/plugins/callback.html
[2] https://docs.ansible.com/ansible/2.8/plugins/callback.html#plugin-list
[3] https://docs.ansible.com/ansible/2.8/plugins/callback/debug.html