Is it reasonable to expect Sudo support in cond to work

[dstull]

@umputun I'm currently trying to compact some of my items down into a smaller list of tasks. To do that, I need to run some commands in the cond area that require sudo to be set.

• current config:

user: ubuntu
ssh_key: /home/ubuntu/.ssh/id_rsa
ssh_shell: /bin/bash
local_shell: /bin/bash
inventory: inventory.yml

tasks:
  - name: Check known rails issue 366450
    targets: ["gitlab_rails"]
    commands:
      - name: Condition check
        script: |
          rm -f /tmp/366450
          version=${GITLAB_VERSION//./}
          if [[ $version -gt 1500 && $version -lt 1630 ]]; then
            touch /tmp/366450
          fi
      - name: Checking for known issue
        script: |
          if grep -s 'OmniAuth::Strategies::SAML' /etc/gitlab/gitlab.rb | grep strategy_class; then
            touch /tmp/366450_warning
          fi
        on_exit: "rm -fv /tmp/366450"
        options: {ignore_errors: true, sudo: true}
        cond: "test -f /tmp/366450"
      - name: Display warning message
        echo: "If you're using SAML for OmniAuth you might be running into known issue https://gitlab.com/gitlab-org/gitlab/-/issues/366450"
        cond: "test -f /tmp/366450_warning"
      - name: Cleanup temp files
        script: |
          rm -fv /tmp/366450_warning
        options: {ignore_errors: true, sudo: true}
  - name: Fake issue that will fail
    targets: ["gitlab_rails"]
    commands:
      - name: Condition check
        script: |
          rm -f /tmp/fake
          version=${GITLAB_VERSION//./}
          if [[ $version -gt 1500 && $version -lt 1700 ]]; then
            touch /tmp/fake
          fi
      - name: Checking condition for known fake issue
        script: |
          if grep -s "gitlab_backup_cli\['dir'\]" /etc/gitlab/gitlab.rb | grep '/var/opt/gitlab/backups'; then
            touch /tmp/fake_warning
          fi
        on_exit: "rm -fv /tmp/fake"
        options: {ignore_errors: true, sudo: true}
        cond: "test -f /tmp/fake"
      - name: Display warning message
        echo: "If this is set to backups, that is wrong. Make sure you fix that."
        cond: "test -f /tmp/fake_warning"
      - name: Cleanup temp files
        script: |
          rm -fv /tmp/fake_warning
        options: {ignore_errors: true, sudo: true}
  - name: Fake issue that will fail with enhanced cond use
    targets: ["gitlab_rails"]
    commands:
      - name: Checking condition for known fake issue
        script: |
          if grep -s "gitlab_backup_cli\['dir'\]" /etc/gitlab/gitlab.rb | grep '/var/opt/gitlab/backups'; then
            touch /tmp/fake_warning
          fi
        options: {ignore_errors: true, sudo: true}
        cond: |
          version=${GITLAB_VERSION//./}
          [[ $version -gt 1500 && $version -lt 1700 ]]
      - name: Display warning message
        echo: "If this is set to backups, that is wrong. Make sure you fix that."
        cond: "test -f /tmp/fake_warning"
      - name: Cleanup temp files
        script: |
          rm -fv /tmp/fake_warning
        options: {ignore_errors: true, sudo: true}
  - name: Fake issue that will fail with compacted commands style
    targets: ["gitlab_rails"]
    commands:
      - name: Display warning message
        echo: "If this is set to backups, that is wrong. Make sure you fix that."
        options: { ignore_errors: true, sudo: true }
        cond: |
          version=${GITLAB_VERSION//./}
          [[ $version -gt 1500 && $version -lt 1700 && grep -s "gitlab_backup_cli\['dir'\]" /etc/gitlab/gitlab.rb | grep '/var/opt/gitlab/backups' ]]

• output. This should not skip the last command as the grep does get a value if sudo is used :

ubuntu@sr-env-049aca04-omnibus:~$ ./spot -p rails_known_issues.yml --env GITLAB_VERSION:16.0.0
spot v1.16.2-1cf9c8b-2024-12-19T21:34:18Z
[omnibus localhost:22] run task "Check known rails issue 366450", commands: 4
[omnibus localhost:22] completed command "Condition check" {script: /bin/sh -c [multiline script]} (717ms)
[omnibus localhost:22] completed command "Checking for known issue" {script: /bin/sh -c [multiline script]} (335ms)
[omnibus localhost:22] completed command "Display warning message" {skip: Display warning message} (5ms)
[omnibus localhost:22] completed command "Cleanup temp files" {script: /bin/sh -c [multiline script]} (36ms)
[omnibus localhost:22] completed task "Check known rails issue 366450", commands: 4 (1.147s)
[omnibus localhost:22] run task "Fake issue that will fail", commands: 4
[omnibus localhost:22] completed command "Condition check" {script: /bin/sh -c [multiline script]} (226ms)
[omnibus localhost:22] completed command "Checking condition for known fake issue" {script: /bin/sh -c [multiline script]} (53ms)
[omnibus localhost:22] completed command "Display warning message" {echo: If this is set to backups, that is wrong. Make sure you fix that.} (9ms)
[omnibus localhost:22] completed command "Cleanup temp files" {script: /bin/sh -c [multiline script]} (35ms)
[omnibus localhost:22] completed task "Fake issue that will fail", commands: 4 (382ms)
[omnibus localhost:22] run task "Fake issue that will fail with enhanced cond use", commands: 3
[omnibus localhost:22] completed command "Checking condition for known fake issue" {script: /bin/sh -c [multiline script]} (290ms)
[omnibus localhost:22] completed command "Display warning message" {echo: If this is set to backups, that is wrong. Make sure you fix that.} (9ms)
[omnibus localhost:22] completed command "Cleanup temp files" {script: /bin/sh -c [multiline script]} (35ms)
[omnibus localhost:22] completed task "Fake issue that will fail with enhanced cond use", commands: 3 (395ms)
[omnibus localhost:22] run task "Fake issue that will fail with compacted commands style", commands: 1
[omnibus localhost:22] completed command "Display warning message" {skip: Display warning message} (270ms)
[omnibus localhost:22] completed task "Fake issue that will fail with compacted commands style", commands: 1 (328ms)

Further, If I remove the grep conditional like this:

  - name: Fake issue that will fail with compacted commands style
    targets: ["gitlab_rails"]
    commands:
      - name: Display warning message
        echo: "If this is set to backups, that is wrong. Make sure you fix that."
        options: { ignore_errors: true, sudo: true }
        cond: |
          version=${GITLAB_VERSION//./}
          [[ $version -gt 1500 && $version -lt 1700 ]]

I see that sudo use in general for an echo command seems to throw an error too, which seems surprising:

[omnibus localhost:22] run task "Fake issue that will fail with compacted commands style", commands: 1
[omnibus localhost:22] run command "Display warning message"
[omnibus localhost:22]  > sudo /bin/sh -c "/bin/sh -c /tmp/.spot-4197468746377705472/spot-script3140008356"
[omnibus localhost:22]  > sudo "echo \"If this is set to backups, that is wrong. Make sure you fix that.\""
[omnibus localhost:22]  ! sudo: echo "If this is set to backups, that is wrong. Make sure you fix that.": command not found
[omnibus localhost:22] failed command "Display warning message" (241ms)
[omnibus localhost:22] completed task "Fake issue that will fail with compacted commands style", commands: 0 (301ms)

So then I remove the sudo option just to test that theory out and it runs fine, confirming that sudo on an echo doesn't seem to be supported:

  - name: Fake issue that will fail with compacted commands style
    targets: ["gitlab_rails"]
    commands:
      - name: Display warning message
        echo: "If this is set to backups, that is wrong. Make sure you fix that."
        options: { ignore_errors: true }
        cond: |
          version=${GITLAB_VERSION//./}
          [[ $version -gt 1500 && $version -lt 1700 ]]

[omnibus localhost:22] run task "Fake issue that will fail with compacted commands style", commands: 1
[omnibus localhost:22] completed command "Display warning message" {echo: If this is set to backups, that is wrong. Make sure you fix that.} (224ms)
[omnibus localhost:22] completed task "Fake issue that will fail with compacted commands style", commands: 1 (281ms)

So then in the end my questions are:

1. Do you think sudo could be applied to cond run?
2. Do you think my use case makes sense enough to think echo should be able to support running correctly with sudo option set?

[umputun]

It is reasonable to expect sudo to work with both cond and echo. In fact, the current code is supposed to support it, and I'm not sure why it is causing you a problem. I will need to see what's going on and will probably start with a new test cases, specifically for the sudo option, as now it is part of the generic test Test_execCmd, which checks just for some (wait and delete) and another one at a higher level, TestProcess_RunWithSudo, testing script (various types) and copy.

[umputun]

see #245