title | aliases |
---|---|
💻 Self-hosted runners |
Native development can often mean hardware specific tests or application execution, be it for a specific GPU, a custom MCU or special high performance network card.
Also it's common for teams to share a very powerful build server to be able to compile memory heavy C++ template code and even when using a remote compilation cloud one might still want to use these servers in an hybrid setup.
cmake-re
support in this aspects 2 types of selfhosted runner specification :
- CMake RE L1 Digital Twins
- CMake RE L2 On-prem Workers
This page presents how to configure self-hosted runners for CMake RE L1 Digital Twins.
In order to use your own runners self-hosted with cmake-re
you need to manage the lifetime of the runners yourself, CMake RE does this for you with environment that can be virtualized, containerized, self-hosted runners are not managed in this way.
Requirement: The self-hosted runner shall have an ssh-server and a
cmake-re
remote rpc server installed. The same procedure as Custom Environments Setup applies for selfhosted runner prerequisites.
To launch the cmake-re
remote rpc server, cmake-re
needs to be authorized, in this regard you will find SSH public keys generated by cmake-re for each environment type in TIPI_HOME_DIR/.ssh/id_rsa_<environment-name>.pub
that you can authorize on your self-hosted digital twin.
The file specifying how to connect to the selfhosted runner has the following syntax :
{
"address": "tipi@<hostname>",
"port": 22,
"storage_server": "",
"machine_id": "<selfhosted-runner-id>"
}
The file can be passed to cmake-re
in 2 ways :
- Either By setting the environment variable
TIPI_SELFHOSTED_RUNNER
with the full path to yourselfhosted-runner.json
file - Or named
<toolchain-name>.json
stored aside the<toolchain-name>.cmake
to use for the selfhosted runner.
The second option is particularly useful to provide useful default dedicated runners for -DCMAKE_TOOLCHAIN_FILE=
toolchains (for example with custom hardware).