apenella / go-ansible

Go-ansible is a Go package that enables the execution of ansible-playbook or ansible commands directly from Golang applications. It supports a wide range of options for each command, enabling smooth integration of Ansible functionality into your projects.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to see prompt text

its-johnt opened this issue · comments

Hi, thanks for your very helpful library. I'm running into an issue where pause tasks with a prompt won't show the prompt text on stdout unless the user knows there's an invisible prompt, enters something, then hits enter. For instance, the examples/ansibleplaybook-simple-with-prompt example from the repo on my Ubuntu 24.04 system shows:

[johnt@work ~/go-ansible/examples/ansibleplaybook-simple-with-prompt (master =)]$ git rev-parse --short HEAD
73bbde1
[johnt@work ~/go-ansible/examples/ansibleplaybook-simple-with-prompt (master =)]$ ls
ansibleplaybook-simple-with-prompt.go  docker  docker-compose.yaml  input.yml  Makefile
[johnt@work ~/go-ansible/examples/ansibleplaybook-simple-with-prompt (master =)]$ go version
go version go1.22.0 linux/amd64
[johnt@work ~/go-ansible/examples/ansibleplaybook-simple-with-prompt (master =)]$ go run .

PLAY [Test playbook for user input] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [127.0.0.1]

TASK [simple prompt 1] *********************************************************

It stops there, but if you know it's a prompt you can enter the text and hit enter.

If there's any other info I can provide to help, please let me know.

Hi @its-johnt
Thanks for opening that issue. Let me check it and I will get you back.

Hi @its-johnt !
I apologize for the delayed response.

Regarding the issue with the prompt message not showing up, I haven't come to a conclusion yet. However, I've noticed that using vars_prompt instead of the pause task, as shown in the following example, does display the prompt:

- name: Test playbook for user input
  hosts: localhost
  gather_facts: false

  vars_prompt:
    - name: input_this
      prompt: Type in anything
      private: true
    - name: input_that
      prompt: Type in another thing
      private: true
  tasks:

    - name: echo user input this
      debug:
        msg: "You typed this: '{{ input_this }}'"
 
    - name: echo user input that
      debug:
        msg: "You typed that: '{{ input_that }}'"

When executed, the prompt message appears as expected.

❯ go run ansibleplaybook-simple-with-prompt.go
Type in anything:
Type in another thing:

PLAY [Test playbook for user input] ********************************************

TASK [echo user input this] ****************************************************
ok: [127.0.0.1] =>
  msg: 'You typed this: ''asdf'''

TASK [echo user input that] ****************************************************
ok: [127.0.0.1] =>
  msg: 'You typed that: ''asdf'''

PLAY RECAP *********************************************************************
127.0.0.1                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Additionally, setting the private variable in vars_prompt to false has the same behaviour as using the pause task, the prompt message isn't displayed.

Do you think this helps you move forward with fixing the issue?

Thank you!

Hi, thanks for taking a look. Unfortunately vars_prompt won't help us. Mostly we want to print a message when a task fails, then allow the person running the playbook to fix things in the background then hit enter to try running the task again. For now I've split up the prompt into multiple tasks - one debug to show the message we were trying to show in the pause task, followed by a pause task. It's not perfect, but it's certainly an improvement.

Hi @its-johnt!
I need to delve into the Ansible code to understand how it handles the prompt and why it's hidden when running the playbook via go-ansible. From what I've seen, it's not a redirection to stderr or similar.
I'll keep you updated if I discover anything that could improve this behaviour.