Robot Framework tests won't start under MS Windows 10 (VirtualBox virtual machine)

I’ve been pointed to this group for solving the problem with running Robot Framework tests in Windows 10 virtual machine (https://github.com/ansible/ansible/issues/64381).

I’ve successfully run my Robot Framework tests task under various GNU/Linux distributions and desktop environments, but Ansible stuck on that particular task under MS Windows 10. I use ansible_winrm_scheme: http following this issue as I haven’t managed to provision a Windows machine with the default https.

`

ansible 2.9.0
config file = /etc/ansible/ansible.cfg
configured module search path = [‘/home/ipaleka/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
ansible python module location = /home/ipaleka/.local/lib/python3.7/site-packages/ansible
executable location = /home/ipaleka/.local/bin/ansible
python version = 3.7.5rc1 (default, Oct 8 2019, 16:47:45) [GCC 9.2.1 20191008]

Host: Linux ubuntu 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
VirtualBox: 6.0.14_Ubuntu r132055
pywinrm==0.4.1 # and pywinrm==0.4.0
Guest: Windows 10 OS build 18362.418

`

The following is the Vagrantfile I use:

`

Vagrant.configure(2) do |config|

config.vm.define “winvm” do |winvm|
winvm.vm.box = “StefanScherer/windows_10”
winvm.vm.hostname = “winvm”
winvm.vm.provider “virtualbox” do |vb|
vb.name = “winvm”
end
end

config.vm.provider “virtualbox” do |vb|
vb.gui = true
vb.memory = “3072”
vb.cpus = 1
vb.customize [“modifyvm”, :id, “–vram”, “32”]
end

config.vm.provision “ansible” do |ansible|
ansible.verbose = “v”
ansible.compatibility_mode = “2.0”
ansible.playbook = “setup.yml”
end

config.vm.provision “ansible”, run: ‘always’ do |ansible|
ansible.verbose = “v”
ansible.compatibility_mode = “2.0”
ansible.playbook = “tests.yml”
end

end

`

And these are the relevant Ansible parts:

`

  • name: install Python 3 in MS Windows
    hosts: winvm
    vars:
    ansible_winrm_scheme: http
    gather_facts: false
    tasks:

  • name: installing Python
    win_chocolatey:
    name: python
    version: 3.7.5
    state: present

  • name: setup MS Windows machine
    hosts: winvm
    vars:
    ansible_winrm_scheme: http
    remote_user: vagrant
    roles:

  • role: setup

  • name: run tests in vagrant
    hosts: winvm
    vars:
    ansible_winrm_scheme: http
    remote_user: vagrant
    roles:

  • role: tests_win

`

All the needed installation parts and the following unit tests task passed:

`

  • name: running all unit tests
    win_command: “C:\dev\venvs\project\Scripts\activate.bat && pytest”
    args:
    chdir: “C:\dev\project”
    tags: tests

`

but it stuck on the following task:

`

  • name: running all functional tests
    win_command: “C:\dev\project\tests\functional\robotstart.bat test_start.robot”
    args:
    chdir: “C:\dev\project\tests\functional”
    tags: tests

`

I also tried with

`

  • name: running all functional tests
    win_psexec:
    command: C:\dev\arrangeit\tests\functional\robotstart.bat test_start.robot
    interactive: yes
    system: yes
    tags: tests

`

ans with:

`

  • name: running all functional tests
    raw: C:\dev\arrangeit\tests\functional\robotstart.bat test_start.robot
    become_user: System
    tags: tests

`

EXPECTED RESULTS

The same robotstart.bat test_start.robot command run from command prompt works as expected.
Maybe also worth mentioning is that I have to use environment: DISPLAY: ":0" variable in the GNU/Linux machines for the same task.

ACTUAL RESULTS

The task stuck. I have tried with win_command, win_shell, raw and script directives without success. Also by changing executable to cmd, cmd.exe, c:\Windows\System32\cmd.exe, etc., by changing all the possible combinations of relative and absolute path, even by trying to use a service directive win_nssm (following an issue), in other Windows 10 OS builds, etc., all without success.

I run the playbooks through the Vagrant, so the following is the last part of the output of ANSIBLE_DEBUG=1 vagrant up winvm:

TASK [tests_win : running all functional tests] ******************************** 22028 1572864232.71069: sending task start callback 22028 1572864232.71073: entering _queue_task() for winvm/win_command 22028 1572864232.71266: worker is 1 (out of 1 available) 22028 1572864232.71300: exiting _queue_task() for winvm/win_command 22028 1572864232.71310: done queuing things up, now waiting for results queue to drain 22028 1572864232.71313: waiting for pending results... 22571 1572864232.71796: running TaskExecutor() for winvm/TASK: tests_win : running all functional tests 22571 1572864232.71843: in run() - task 27c04189-bf46-0fb7-c2fe-000000000021 22571 1572864232.71882: calling self._execute() 22571 1572864232.72019: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/connection 22571 1572864232.72059: Loading Connection 'winrm' from /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/connection/winrm.py (found_in_cache=True, class_only=False) 22571 1572864232.72072: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/shell 22571 1572864232.72084: Loading ShellModule 'powershell' from /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/shell/powershell.py (found_in_cache=True, class_only=False) 22571 1572864232.72209: Loading ActionModule 'normal' from /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/action/normal.py (searched paths: /home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/action/__pycache__:/home/ipaleka/.local/lib/python3.7/site-packages/ansible/plugins/action) 22571 1572864232.72218: starting attempt loop 22571 1572864232.72221: running the handler 22571 1572864232.73457: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils 22571 1572864232.73555: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/facts 22571 1572864232.73574: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/ecs 22571 1572864232.73581: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/docker 22571 1572864232.73588: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/podman 22571 1572864232.73593: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/k8s 22571 1572864232.73600: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/parsing 22571 1572864232.73606: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/storage 22571 1572864232.73611: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/compat 22571 1572864232.73617: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/distro 22571 1572864232.73622: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/oracle 22571 1572864232.73628: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/identity 22571 1572864232.73633: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/common 22571 1572864232.73650: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/network 22571 1572864232.73675: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/six 22571 1572864232.73681: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/aws 22571 1572864232.73698: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/source_control 22571 1572864232.73705: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/powershell 22571 1572864232.73763: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/__pycache__ 22571 1572864232.73816: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/remote_management 22571 1572864232.73825: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/net_tools 22571 1572864232.73830: trying /home/ipaleka/.local/lib/python3.7/site-packages/ansible/module_utils/csharp 22571 1572864232.74263: _low_level_execute_command(): starting 22571 1572864232.74278: _low_level_execute_command(): executing: PowerShell -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -EncodedCommand JgBjAGgAYwBwAC4AYwBvAG0AIAA2ADUAMAAwADEAIAA+ACAAJABuAHUAbABsAAoAJABlAHgAZQBjAF8AdwByAGEAcABwAGUAcgBfAHMAdAByACAAPQAgACQAaQBuAHAAdQB0ACAAfAAgAE8AdQB0AC0AUwB0AHIAaQBuAGcACgAkAHMAcABsAGkAdABfAHAAYQByAHQAcwAgAD0AIAAkAGUAeABlAGMAXwB3AHIAYQBwAHAAZQByAF8AcwB0AHIALgBTAHAAbABpAHQAKABAACgAIgBgADAAYAAwAGAAMABgADAAIgApACwAIAAyACwAIABbAFMAdAByAGkAbgBnAFMAcABsAGkAdABPAHAAdABpAG8AbgBzAF0AOgA6AFIAZQBtAG8AdgBlAEUAbQBwAHQAeQBFAG4AdAByAGkAZQBzACkACgBJAGYAIAAoAC0AbgBvAHQAIAAkAHMAcABsAGkAdABfAHAAYQByAHQAcwAuAEwAZQBuAGcAdABoACAALQBlAHEAIAAyACkAIAB7ACAAdABoAHIAbwB3ACAAIgBpAG4AdgBhAGwAaQBkACAAcABhAHkAbABvAGEAZAAiACAAfQAKAFMAZQB0AC0AVgBhAHIAaQBhAGIAbABlACAALQBOAGEAbQBlACAAagBzAG8AbgBfAHIAYQB3ACAALQBWAGEAbAB1AGUAIAAkAHMAcABsAGkAdABfAHAAYQByAHQAcwBbADEAXQAKACQAZQB4AGUAYwBfAHcAcgBhAHAAcABlAHIAIAA9ACAAWwBTAGMAcgBpAHAAdABCAGwAbwBjAGsAXQA6ADoAQwByAGUAYQB0AGUAKAAkAHMAcABsAGkAdABfAHAAYQByAHQAcwBbADAAXQApAAoAJgAkAGUAeABlAGMAXwB3AHIAYQBwAHAAZQByAA== 22571 1572864232.74343: checking if winrm_host 127.0.0.1 is an IPv6 address

The following is the output of win_whoami:

`

TASK [tests_win : win_whoami] **************************************************
ok: [winvm] => {
“account”: {
“account_name”: “vagrant”,
“domain_name”: “WINVM”,
“sid”: “S-1-5-21-2452099938-1091992757-2462325043-1000”,
“type”: “User”
},
“authentication_package”: “NTLM”,
“changed”: false,
“dns_domain_name”: “”,
“groups”: [
{
“account_name”: “None”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “WINVM”,
“sid”: “S-1-5-21-2452099938-1091992757-2462325043-513”,
“type”: “Group”
},
{
“account_name”: “Everyone”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “”,
“sid”: “S-1-1-0”,
“type”: “WellKnownGroup”
},
{
“account_name”: “Local account and member of Administrators group”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-114”,
“type”: “WellKnownGroup”
},
{
“account_name”: “Administrators”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”,
“Owner”
],
“domain_name”: “BUILTIN”,
“sid”: “S-1-5-32-544”,
“type”: “Alias”
},
{
“account_name”: “Users”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “BUILTIN”,
“sid”: “S-1-5-32-545”,
“type”: “Alias”
},
{
“account_name”: “NETWORK”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-2”,
“type”: “WellKnownGroup”
},
{
“account_name”: “Authenticated Users”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-11”,
“type”: “WellKnownGroup”
},
{
“account_name”: “This Organization”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-15”,
“type”: “WellKnownGroup”
},
{
“account_name”: “Local account”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-113”,
“type”: “WellKnownGroup”
},
{
“account_name”: “NTLM Authentication”,
“attributes”: [
“Mandatory”,
“Enabled by default”,
“Enabled”
],
“domain_name”: “NT AUTHORITY”,
“sid”: “S-1-5-64-10”,
“type”: “WellKnownGroup”
},
{
“account_name”: “High Mandatory Level”,
“attributes”: [
“Integrity”,
“Integrity enabled”
],
“domain_name”: “Mandatory Label”,
“sid”: “S-1-16-12288”,
“type”: “Label”
}
],
“impersonation_level”: “SecurityAnonymous”,
“label”: {
“account_name”: “High Mandatory Level”,
“domain_name”: “Mandatory Label”,
“sid”: “S-1-16-12288”,
“type”: “Label”
},
“login_domain”: “WINVM”,
“login_time”: “2019-11-06T02:45:53.0143972-08:00”,
“logon_id”: 764431,
“logon_server”: “WINVM”,
“logon_type”: “Network”,
“privileges”: {
“SeBackupPrivilege”: “enabled-by-default”,
“SeChangeNotifyPrivilege”: “enabled-by-default”,
“SeCreateGlobalPrivilege”: “enabled-by-default”,
“SeCreatePagefilePrivilege”: “enabled-by-default”,
“SeCreateSymbolicLinkPrivilege”: “enabled-by-default”,
“SeDebugPrivilege”: “enabled-by-default”,
“SeDelegateSessionUserImpersonatePrivilege”: “enabled-by-default”,
“SeImpersonatePrivilege”: “enabled-by-default”,
“SeIncreaseBasePriorityPrivilege”: “enabled-by-default”,
“SeIncreaseQuotaPrivilege”: “enabled-by-default”,
“SeIncreaseWorkingSetPrivilege”: “enabled-by-default”,
“SeLoadDriverPrivilege”: “enabled-by-default”,
“SeManageVolumePrivilege”: “enabled-by-default”,
“SeProfileSingleProcessPrivilege”: “enabled-by-default”,
“SeRemoteShutdownPrivilege”: “enabled-by-default”,
“SeRestorePrivilege”: “enabled-by-default”,
“SeSecurityPrivilege”: “enabled-by-default”,
“SeShutdownPrivilege”: “enabled-by-default”,
“SeSystemEnvironmentPrivilege”: “enabled-by-default”,
“SeSystemProfilePrivilege”: “enabled-by-default”,
“SeSystemtimePrivilege”: “enabled-by-default”,
“SeTakeOwnershipPrivilege”: “enabled-by-default”,
“SeTimeZonePrivilege”: “enabled-by-default”,
“SeUndockPrivilege”: “enabled-by-default”
},
“rights”: [
“SeNetworkLogonRight”,
“SeInteractiveLogonRight”,
“SeBatchLogonRight”,
“SeRemoteInteractiveLogonRight”
],
“token_type”: “TokenPrimary”,
“upn”: “”,
“user_flags”:
}

`

As pointed by @jborean93, that’s the problem with that Session 0, but I can’t get it working interactively. Also, this can’t be solved by using older Windows machines because the plan is to create functional tests in real environment.

TL; DR Can’t run Robot tests (the very first keyword Start Process C:\Program\ Files\Inkscape\inkscape.exe .\resources\sample.svg) from Ansible, while they run as expected from command prompt inside virtual machine.

I’ll try to help a bit more but unfortunately the repo you linked to in the issue is hard to follow along. It shows you are running a batch file and subsequently calling a .robot file which is something particular to the application you are testing. This makes it really hard to figure out what is actually going on, I can’t even see where ‘Start Process …’ is called and subsequently know what and how that is starting the process.

I’m just going to assume that this is starting a process called inkscape which is some sort of graphics editor and telling it to open the file you specified. Maybe that is happening, maybe not as I cannot see how you determine that’s where the hang is occuring. In any case you should be using a tool like ProcExp to determine what is still running in the background. As an example I have the following Ansible task.

`

  • hosts: windows
    gather_facts: no
    tasks:
  • win_shell: Start-Sleep -Seconds 5

`

While it is running I can see the following process tree

Let’s break this down a bit more;

  • winrshost.exe (4960) - Spawned when Ansible creates the WinRM shell, will stay alive until the task is complete

  • conhost.exe (4984) - A special process that is creates as the console host whenever a console process is added (cmd.exe below)

  • cmd.exe (1208) - Spawned by the WinRM shell to run the command that is desired across WinRM

  • powershell.exe (2744) - Ansible requires a consistent shell experience so the first command we run through cmd.exe is to start PowerShell with our wrapper, this process then kicks off a new powershell instance which runs the module (win_shell.ps1)

  • powershell.exe (2928) - The module wrapper that runs the win_shell module code

  • powershell.exe (3664) - The actual win_shell invocation value running, i.e. ‘powershell.exe -Command Start-Sleep -Seconds 5’

Typically each process is waiting on the children to end and Ansible is waiting it’s processes and WinRM shell to end and close before continuing on. This has lead to some weird and rare scenarios where Ansible kicks off an installer which then runs a detached process (outside of the WinRM job) in the background but it inherits the console (conhost.exe) of the cmd.exe process [1]. Because of this the module and everything has finished but conhost.exe stayed open because the background job was still using it. The ultimate fix for that scenario was to use async [2] on the job which separates the module invocation from the WinRM job to avoid an issue like that. This may or may not help you but it’s worth a shot.

What I recommend you do is to run your process and have Process Explorer open and to see what processes are still running when Ansible hangs. You can see the process tree to determine how it go there and you will see what process is still running to cause Ansible to wait. Feel free to share some screenshots and more details of the actual workflow with us when you have more info.

[1] win_shell / win_command task stuck on execution from 2.5.1 onwards · Issue #44905 · ansible/ansible · GitHub

[2] https://docs.ansible.com/ansible/latest/user_guide/playbooks_async.html#concurrent-tasks-poll-0

Thanks

Jordan

First of all, thank you very much Jordan for your time! :slight_smile:

I’ll try to help a bit more but unfortunately the repo you linked to in the issue is hard to follow along. It shows you are running a batch file and subsequently calling a .robot file which is something particular to the application you are testing. This makes it really hard to figure out what is actually going on, I can’t even see where ‘Start Process …’ is called and subsequently know what and how that is starting the process.

As the introduction, I should say I linked arrangeit just to give a way to completely reproduce the error.

So there’s a script that activates Python virtual environment (and so gives us access to Robot Framework too) and runs it with provided test_start.robot:

..\..\..\venvs\arrangeit\Scripts\activate.bat && robot --loglevel=DEBUG %1

Inside that test_start.robot there’s a Settings section:

`
*** Settings ***
Resource software_setup.robot
Test Setup Start Programs

`

And that tells us that prior running any test, Start Programs keyword is run. And that is (after checking a condition in Start Programs from the resource file):

`
Start Programs Windows
Start Process C:\Program\ Files\Inkscape\inkscape.exe .\resources\sample.svg
Start Process C:\Program\ Files\GIMP\ 2\bin\gimp-2.10.exe .\resources\sample.xcf
Start Process C:\Program\ Files\LibreOffice\program\soffice.exe --calc .\resources\sample.ods --norestore
Start Process C:\Program\ Files\LibreOffice\program\soffice.exe --writer .\resources\sample.odt --norestore
Start Process C:\Program\ Files (x86)\gedit\bin\gedit.exe .\resources\sample.txt
Sleep 15s
${arr_handle} = Start Process arrangeitstart.bat
Set Suite Variable ${arr_handle}
Sleep 4s

`

When I run that initial script from command prompt inside Windows 10 virtual machine (or when I run tests for GNU/Linux platform), Robot Framework opens all of those programs (that I installed through an Ansible playbook) with the provided files and so it provides the testing environment for arrangeit. arrangeit itself isn’t involved here during these first five tasks and one could have reproduced this without it.

That being said, let’s move to an excellent advice I’ve got from you. Ansible actually did start those programs, but the problem is that current display “don’t have” them. I believe that is that “Session 0” topic @jborean93 was talking about.

This is a screenshot taken while Ansible task was frozen:

And this is a screenshot taken when the same script was run from the command prompt:

Just a side note, I stripped down the tests to a bare minimum, just to see am I going to be able to test my app even without showing it on screen.

But, autopy complains:

`
Version:1.0
StartHTML:000000157
EndHTML:000004835
StartFragment:000000189
EndFragment:000004803
SourceURL:file:///C:/dev/arrangeit/tests/functional/log.html

Start / End / Elapsed: | 20191107 08:07:08.473 / 20191107 08:07:08.473 / 00:00:00.000 |

  • | - |

08:07:08.473 | FAIL | OSError: Not enough data was provided to the Decoder to decode the image | |

  • | - | - | - |

08:07:08.473 | DEBUG | Traceback (most recent call last):
File “C:\dev\arrangeit\tests\functional\arrangeit_keywords.py”, line 34, in locate_image
screen = autopy.bitmap.capture_screen() |

  • | - | - |

`

So I think you found the problem there, the tests are failing because as expected it was unable to capture a screen or Window. My guess is that your test suite is failing but is then not cleaning up the programs that it spawns. Thus Ansible still thinks it is running (because the programs are still open) and will continue to wait until that is not the case. Hopefully you can ammend you test suite to kill the processes that it spawns.

As for the error about not capturing the screen I think you will be mostly out of luck. There are 2 things I think you can do if you still want to go down the route of automated testing but they are not pretty. Basically what I think you can do is set up the host to auto login as a local user on reboot that then runs your test suite. You can either set the tests to run on login automatically or get Ansible to spawn them but I think the former will be easiest.

Here is what a basic workflow may look like (I have not tested this so it probably needs some tweaks):

`

  • name: Set the host to auto logon on reboot
    win_regedit:
    path: HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    name: ‘{{ item.name }}’
    data: ‘{{ item.value }}’
    type: ‘{{ item.type }}’
    state: present
    with_items:

  • name: DefaultUserName
    value: local user
    type: string

  • name: DefaultPassword
    value: user password
    type: string

  • name: AutoAdminLogon
    value: 1
    type: dword

  • name: Set test suite to run on next logon
    win_regedit:
    path: HKLM:\SOFTWARE\Microsoft\Windows\RunOnce
    name: RobotTesting
    data: C:\Windows\System32\cmd.exe /c C:\dev\project\tests\functional\robotstart.bat test_start.robot
    type: string
    state: present

  • name: Reboot the Windows host to kick off the tests
    win_reboot:

We first need to get the PID before we can wait for it to finish

  • name: Find the pid of the process
    win_wait_for_process:
    process_name_exact: robot
    state: present
    register: process_info

  • name: Wait for the tests to complete
    win_wait_for_process:
    pid: ‘{{ process_info.matched_processes[0].pid }}’
    state: absent
    timeout: 600 # 10 minutes, set to what you need

INSERT TASKS TO GET TEST RESULTS AND ASSERT SUCCESS HERE

INSERT CLEANUP REGISTRY TASKS HERE

`

If you want Ansible to spawn the tests directory you can but you will need to do 2 things;

  • Get the Session Id of the logged in user, this should be 1 but that may not be the case in all scenarios

  • Use psexec with -s -i <session id> to run the program on the desktop of the session specified

Hopefully this helps you further and good luck with it all.

Hi Jordan!

Thank you very much for your help, I’ve managed to run the tests with PsExec using hard-coded session as 1.

`

  • name: running all functional tests
    win_psexec:
    command: cmd.exe /c “C:\dev\arrangeit\tests\functional\robotstart.bat c:\dev\arrangeit\tests\functional\test_start.robot”
    interactive: yes
    session: 1
    system: yes
    tags: tests

`

And also I changed my batch script to use the absolute path for Robot Framework:

`
c:\dev\venvs\arrangeit\Scripts\activate.bat && cd c:\dev\arrangeit\tests\functional && C:\dev\venvs\arrangeit\Scripts\robot.exe --loglevel=DEBUG %1

`

Thank you very much for your help!