The build pipeline consists of one service application, which can be run as either master or slave. You must run at least one master, either locally or on an external build server. Slaves may be run additionally, either locally for each additional simultaneous build process you wish to run, or externally for each simultaneous build process on an external server.
All build services must be able to connect to the same network hard drive for reading leveldesign and database, as well as for writing build output. This may also be a local path if you are running all services locally on one machine.
A Pipeline Client application may be used to connect to the master pipeline service remotely. The client does not need to be able to have access to the network hard drive. The service allows the client to browse trough build file structures remotely, call commands, list build input and output errors, etcetera.
Required is a storage device that can be shared between multiple physical machines. A generic shared folder with write permissions is sufficient. There are two main directories that need to be identical across build machines. The first is the
work directory, which contains the
database directory extracted from the ryzom assets archive as well as an initially empty
workspace directory which is used by the services to store metadata. By default this is configured as
W: on Windows and as
/srv/work on Linux. You can use drive mapping or directory linking to save work on configuration. The second is the
leveldesign directory, which is configured as
/srv/leveldesign on Windows and Linux respectively. This maps to the
data_leveldesign directory residing in a copy of the repository on the shared storage, in order to ensure consistency across all machines. The repository must be kept up to date with the repositories used by the leveldesigners. [? The repository can be configured to be automatically pulled and updated when a build is started ?]
The necessary configuration files for a basic installation are provided under
Any modifications to the default
*.cfg files should be done under the user directory inside this folder, these will override the default values. There is a common configuration file, and one for Linux and Windows each.
Make a copy of the
example_cfg folder in a user directory of choice. It is allowed for configuration values to be different on different physical machines in order to accommodate for available toolsets or capabilities. Keep in mind that you may need to update your default configuration files when new features are released in the pipeline.
Modify the paths to the service executables and to your configuration directory in the
*.bat files for Windows and in the
*.sh files for Linux.
You must configure the hostname of the master service in
user/pipeline_service_user.cfg by adding the line
MasterAddress = "hostname";. By default this is
localhost. [? A line
MasterSlavePassword = "yourpasswordhere"; must also be added in order for the services to acknowledge each other. ?]
In case you are not using standard directories for the
leveldesign directories, modify
user/pipeline_service_user_linux.cfg, adding in
SharedWork = "path"; and
SharedLeveldesign = "path";.
You can run the master service which runs with a builtin slave by using the
linux_run_master.sh. On each build machine, for each additional build thread required, run the
The build workspace is configured using georges sheets. Refer to process specific manuals for more information.
How to setup the pipeline locally?¶
- Configure the
"localhost", and set all directories.
- For each additional simultaneous process you want, run