Ansible extension doesn't work with Gitlab extension

[Igorgro]

Sanity check

• [X] I certify that the redhat.ansible extension is in use and the language of the document in this bug report shows up as Ansible

Summary

When opening any ansible file in gitlab merge request using gitlab extension none of Ansible features are available and the status bar item says "Ansiblw not found in the environment". Also when opening file in merge request the following error appears:

Extension version

0.12.30

VS Code version

1.70.2

Ansible Version

ansible [core 2.13.3]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/igormahov/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.10/site-packages/ansible
  ansible collection location = /home/igormahov/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.6 (main, Aug  3 2022, 17:39:45) [GCC 12.1.1 20220730]
  jinja version = 3.1.2
  libyaml = True

OS / Environment

OS is Arch Linux

Relevant log output

No response

[ssbarnea]

Are you sure this has anything to do with gitlab extension? Have you tried without it? Does /bin/sh really exists on your systems as that is what ENOENT indicates.

[Igorgro]

Yes, when I'm editing regular files themself everything works normally. This issue ony happens when I'm openning diff from gitlab extension

[ssbarnea]

A diff is not really compatible with the same two files it originated from, no wonder that it does not work. Still, I am curious why you see the /bin/sh error only in that case, as I do not see how that would be caused by the diff.

Can you post the filename of the diff, the language server reported by vscode in status bar and maybe even its content. Maybe you can reproduce the problem by having a standalone file and opening that one? The file-name-and-path is essential for how ansible extension works as that is used to determine the file type. If we can reproduce the error without involving gitlab extension we might be able to find a way to avoid it.

[Igorgro]

It really doesn't depends on file name and it's content. You can reproduce by the following (I cannot give you an access to my repository, because it is private)

1. Create repository with ansible role on gitlab.com
2. Create a merge request which affects tasks/main.yml
3. Install vscode gitlab extension and authorize it using personal access token
4. Open the diff from merge request in vscode using gitlab extension (select gitlab in activity panel -> all project merge requests -> !1 -> select diff)

When I'm opening the diff using other tools: git history, git graph, git lens, I can't reproduce it, it seems that this problem is connected with gitlab extension only.

P.S. If you have no much time, I can create public repro repository, just send me you Gitlab nickname.

[Igorgro]

I enabled ansible lsp log and found that this issue is caused by gl-review prefix of the opened file:

[Trace - 19:18:33] Sending request 'textDocument/semanticTokens/full - (9)'.
Params: {
    "textDocument": {
        "uri": "gl-review:/roles/cloud_images/tasks/main.yml?%7B%22commit%22%3A%228d6a4e577304a6641fe00ef0a9a2ccd55d09c7e1%22%2C%22mrId%22%3A8821%2C%22projectId%22%3A7902%2C%22repositoryRoot%22%3A%22%2Fhome%2Figormahov%2Fdev%2Fansible%22%7D"
    }
}


[Trace - 19:18:33] Sending notification 'update/ansible-metadata'.
Params: [
    [
        "gl-review:/roles/cloud_images/tasks/main.yml?%7B%22commit%22%3A%228d6a4e577304a6641fe00ef0a9a2ccd55d09c7e1%22%2C%22mrId%22%3A8821%2C%22projectId%22%3A7902%2C%22repositoryRoot%22%3A%22%2Fhome%2Figormahov%2Fdev%2Fansible%22%7D"
    ]
]


[Trace - 19:18:33] Received response 'textDocument/semanticTokens/full - (9)' in 2ms.
Result: {
    "data": []
}


[Trace - 19:18:33] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "workspace folder explicitly set to /roles/cloud_images/tasks"
}


workspace folder explicitly set to /roles/cloud_images/tasks
[Trace - 19:18:33] Received request 'workspace/configuration - (8)'.
Params: {
    "items": [
        {
            "scopeUri": "gl-review:/roles/cloud_images/tasks",
            "section": "ansible"
        }
    ]
}


[Trace - 19:18:33] Sending response 'workspace/configuration - (8)'. Processing request took 1ms
Result: [
    {
        "ansible": {
            "path": "ansible",
            "useFullyQualifiedCollectionNames": true
        },
        "ansibleLint": {
            "arguments": "--offline",
            "enabled": true,
            "path": "/usr/bin/ansible-lint"
        },
        "ansibleNavigator": {
            "path": "ansible-navigator"
        },
        "executionEnvironment": {
            "containerEngine": "auto",
            "enabled": false,
            "image": "quay.io/ansible/creator-ee:latest",
            "containerOptions": "",
            "pull": {
                "arguments": "",
                "policy": "missing"
            },
            "volumeMounts": []
        },
        "python": {
            "activationScript": "",
            "interpreterPath": "python3"
        }
    }
]


[Trace - 19:18:33] Received request 'window/showMessageRequest - (9)'.
Params: {
    "type": 1,
    "message": "spawn /bin/sh ENOENT",
    "actions": []
}


cmd 'python --version' was not executed with the following error: ' Error: spawn /bin/sh ENOENT
cmd 'ansible-lint --version' was not executed with the following error: ' Error: spawn /bin/sh ENOENT
[Trace - 19:18:33] Received notification 'update/ansible-metadata'.
Params: [
    [
        {
            "ansible information": {},
            "python information": {},
            "ansible-lint information": {}
        }
    ]
]

[ssbarnea]

@ganeshrn @priyamsahoo ^ that uri is interesting. WDYT?

[priyamsahoo]

It seems like the extension is trying to execute commands in a remote workspace rather than on the local workspace.

[ssbarnea]

@Igorgro Did you use a devenv, remote-connection or just run vscode in default mode (local)? If not, maybe gitlab extension does something special with diffs and opens them inside a remote container or similar.

Priyam is right to suspect this, because that is what happens if that command is executed on a "machine" that does not have python, ansible or the linter.

[Igorgro]

No, I don't use any environments, I think it's internal details of how gitlab diffs are implemented

[ssbarnea]

I think it is the time to open a sister ticket on gitlab-extension repository and cross-link with this one. I am not sure if it in our power to control where this runs. They might know more about this. I suspect that any tool that looks at the diff file and tries to run an external command, would be affected by this issue.