Robot Framework tests won't start under MS Windows 10 (VirtualBox virtual machine)
87 views
Skip to first unread message
ipaleka
Nov 6, 2019, 7:01:41 AM11/6/19
to Ansible Project
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](https://github.com/hashicorp/vagrant/issues/10765) 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/LinuxVirtualBox: 6.0.14_Ubuntu r132055pywinrm==0.4.1 # and pywinrm==0.4.0Guest: Windows 10 OS build 18362.418The 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
endAnd 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_winAll 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](https://github.com/ansible/ansible/issues/25004)), 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 addressThe 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.
Jordan Borean
Nov 6, 2019, 6:17:35 PM11/6/19
to Ansible Project
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.
Thanks
Jordan
ipaleka
Nov 7, 2019, 5:23:47 AM11/7/19
to Ansible Project
First of all, thank you very much Jordan for your time! :)
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 %1Inside 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:
ipaleka
Nov 7, 2019, 11:17:19 AM11/7/19
to Ansible Project
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()
Jordan Borean
Nov 8, 2019, 12:28:33 AM11/8/19
to Ansible Project
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.
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
Hopefully this helps you further and good luck with it all.
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* 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.
ipaleka
Nov 8, 2019, 5:24:28 AM11/8/19
to Ansible Project
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!
Reply all
Reply to author
Forward
0 new messages