Rcc.exe

[Suyay Escarsega]

Icreated my project GUI in QtDesigner and also use the image in the GUI. Then, I generate .py from .ui file using pyside-uic and it works! Then I have to generate my resource file, .qrc file, to .py file to use with my project.

Right click on My Computer and go to Properties. Then click on Advanced System Settings. Under the Advanced tab, click on the "Environment Variables..." button. A new window will open up and you will see a list showing "System variables". Scroll to the "Path" system variable, and either double click it or click the "Edit..." button. At the beginning of the "Variable value:" entry, put in the directory to the folder that contains pyside-rcc.exe and put a semicolon (;) after it, like below:

Or put the directory at the end, but with the semicolon in front of it (after the last entry). After doing this, you either have to logout and log back in or reboot in order for Windows to recognize the PATH changes. That should do the trick.

It seems the correct path is not being used for rcc.exe in Windows/MinGW. For some reason it is not looking in Qt's \bin directory but instead is looking for rcc.exe in a folder called 'bin' in the currect working directory which in this case is `E:/Buildsys/svn/smtube/src'.

In 4.8.2, compiled using the same exact compiler, doesn't exhibit this problem. As you see it simply says "bin\rcc.exe" instead of "E:\Buildsys\Qt\4.8.3_x64\bin\rcc.exe" where it was compiled in. It doesn't appear that any of the other executables like moc and uic have problems, for example they are exhibiting the correct behavior by using the full path name:

The Checkmk agent, which we will install soon, will include the rcc.exe binary. You can therefore skip this step here if you want to integrate the robot into Checkmk immediately (i.e. without prior testing).

I have got into the habit of creating a bin directory in the user profile and putting the binary there like this: c:\Users\simonmeggle\bin\rcc.exe

For a prior test or to set up a development host, you will need to obtain the RCC binary yourself. Download it here (version v17.18 is the current one at the time of writing) and save it to a location of your choice.

Creating the environment for the web test web/cmk_synthetic_web takes a few minutes (Python packages, NodeJS, …).

If you want to start an absolute minimal example, you can alternatively use the robot minimal from the demo repo.

In this case, nothing else is installed apart from Robot Framework.

I'm currently testing ftrack to see if I can integrate it into my workflow. Sadly, the issue I have is that ftrack-connect doesn't seem to be working with Python3 (which is what I have been using to make my tools in blender and Houdini)

When I'm launching houdini from ftrack-launcher, I don't have access to 'Import Asset' tool, or anything related to ftrack. I also tried to import the ftrack_api to see if that was working but it's not neither. I got this message:

we are actively working on connect for python on 3 .If you like to give it a go , you can try this branch

This new version though is not compatible with the current integrations ., but we are working on solutions to make them work back, just not there yet.

I'm currently trying to build it. For now, I get an error telling me pySide-rcc could not be found, but I think it's coming from my system, as I found the 'pyside2-rcc.exe' file, it's in my path but I can't start it

I have two environment variables, one called 'FTRACK_SERVER' and the other 'FTRACK_API_KEY'. For the API_KEY, I took the one which is visible in my account settings. Is there anything else needed to do?

For now, this is a mostly machine translated version of the same article in German.It has been proofread by some non-native English speaker to provide a minimal viable article to start your endeavors with Robotmk.We believe it is better for the planet to do LLM (Large Language Model) translation only once (and do an initial proofreading for better quality) than pointing our readers to their favorite online translation tool and translate based on the German version over and over (with varying quality).

Checkmk Synthetic Monitoring is available in the commercial Checkmk editions, but requires an additional subscription.However, you can test the function with up to three tests free of charge and without a time limit.

The automation software can be used to completely automate user behavior, for example to simulate order processes in online stores click by click.The special thing about Robot Framework is that tests are not written in a fully-fledged programming language, but are defined using easy-to-use keywords such as Open Browser or Click Button.An Open Browser checkmk.com is sufficient to call up the Checkmk website.Several test cases are then combined in so-called test suites (in the form of a .robot file).

Robotmk can now trigger these robot framework test suites on the host and monitor their execution and results as services in Checkmk.In the Checkmk web interface you will then find the status, associated performance graphs and the original evaluations of Robot Framework itself.

In monitoring, you will ultimately receive several new services: RMK Scheduler Status shows the status of the scheduler itself, i.e. whether test suites could be started successfully.There are also services for all configured test plans (such as RMK MyApp1 Plan) and individual tests from test suites (such as RMK MyApp1 Test).The services of the individual tests also include the original Robot Framework reports.

You must provide the Robot Framework test suites on a Windows host.For execution, Robot Framework requires access to their dependencies (Python, libraries, drivers for browser automation and so on).This configuration is independent of Checkmk and can be stored declaratively in a portable package.This is done by the open source command line tool RCC:This tool uses your configuration files in YAML format to build virtual Python environments including dependencies and the Robot Framework itself.The Robotmk scheduler running as a background process triggers this build and then executes the tests itself.

Such an RCC automation package with the package configuration (robot.yaml), the definition of the execution environment (conda.yaml) and the test suites (tests.robot) is also called Robot.RCC and the scheduler are rolled out with the Checkmk agent, the automation package must be available on the host.

In the following, we will show you how to include a test suite in the monitoring and monitor it.A simple Hello World suite is used as an example, which only outputs two strings and waits briefly in between.An introduction to Robot Framework is of course not the topic here, but a brief look at the automation package and the demo test suite is necessary so that you can see which data ends up where in the monitoring.

The example runs on the basis of RCC, so that the Windows host does not have to be configured separately.The rcc.exe is rolled out with the agent and can be found under C:\ProgramData\checkmk\agent\bin\.You can download the sample suite as a ZIP file via GitHub.The directory of the suite:

The suite folder now contains two important files: The declaration of the environment required for execution in the file conda.yaml and the actual tests in the file tests.robot (the suite).The robot.yaml is not relevant for use in Checkmk, but is required by RCC.

In this case, only the Python, Pip and Robot Framework dependencies are installed for the environment.The environment build later appears in the monitoring as RCC environment build status.The tests can only be processed and consequently monitored if the environment is built successfully.

You can run this test suite manually.To do this, the agent and RCC must already be installed (or you can download the RCC binary yourself).First navigate to your test suite folder, where the tests.robot is also located.Then start the RCC shell with C:\ProgramData\checkmk\agent\bin\rcc.exe task shell.The virtual environment defined in conda.yaml is then created.Then start the suite with robot tests.robot.

Attention: The plans in the plan group naturally have a certain runtime themselves, determined by the timeout of a single execution and the maximum number of repeated executions in the event of failed tests.The execution interval of the plan group must therefore be greater than the sum of the maximum runtimes of all plans in the group.The maximum runtime of a plan is calculated as follows: Limit per attempt (1 + Maximum number of re-executions).

However, the specification under Relative path to test suite file or folder. is necessary.The path is relative to the base directory specified above, e.g. mybot\test.robot for C:\robots\.Alternatively, a directory (with several robot files) can also be specified here, in which case it would simply be mybot.

In the case of complete retries, only self-contained suite results are taken into account for the final result: If a test fails on the last retry, the test suite is counted as a failure.In the case of incremental retries, the final result is made up of the best partial results: If some tests only run successfully on the third attempt, the final result is also counted as a success.Reminder: The combination of attempts and maximum run times of all plans in a plan group determines their minimum execution interval.

By default, execution via RCC is activated under Automated environment setup (via RCC), for which you must enter two values.Firstly, RCC requires the specification of where the robot.yaml file is located.Its primary purpose is to reference the conda.yaml file, which is responsible for setting up the Python environment, i.e. installing Python and dependencies.This specification is relative to the base directory that you have set above under Relative path to test suite file or folder.The YAML files can be saved in subfolders, but best practice is the top suite directory!For the above base directory C:\robot\ and the suite directory C:\robot\mybot it is accordingly mybot\robot.yaml.

3a8082e126