Menu
The YAML snippets below call our predefined Solsta GitHub actions to deploy and promote releases within the Solsta ecosystem. Deploying consists of converting and uploading raw files (assets) to a bucket in order to make releases available for download by Solsta desktop clients. These sample YAML snippets are meant to demonstrate a basic deployment and promotion using the Solsta deployment tools running within a docker container. You can modify these snippets as necessary to fit your GitHub Actions deployment pipeline.
Article updated February 20th, 2023 for deploy action version 2 or later.
The deployment and promotion actions run within our docker container. They can be run on Linux or Windows agents that support loading docker containers. We recommend using either the “ubuntu-latest” or “windows-latest” shared runners from GitHub. Read more about GitHub-hosted runners.
If you prefer to run these actions in your own runners, they will need to have the following components installed:
The Solid State Networks deployment tools require authentication using M2M credentials that were provided when your company signed up for Solsta. Contact your company’s primary contact with Solid State Networks or open a support ticket for assistance.
The YAML examples below require the credentials to be set as two repository secrets before executing a pipeline.
These variables can be set in the Settings > Secrets > Actions section of your GitHub repository where they can be protected and masked (see image below for an example).
In the deployment snippet below, custom CI/CD variables are defined for the following:
Note that the values for product, environment and repository are case-sensitive. If the specified product, environment and repository do not exist, they will be automatically created.
working_directory: /github/workspace/mybuilds/v38.1.2
See the docker container fileystem section on GitHub Docs for more information.
steps:
- name: Deploy Build Assets from bin/ directory
uses: snxd/deploy-github-deploy-action@v2
with:
working_directory: 'bin/'
console_version: '6.1.2.84'
scripts_version: '3.7.30'
release_version: '1.0'
target_product: 'llamacraft'
target_environment: 'dev-nightly'
target_repository: 'game-client'
solsta_client_id: ${{ secrets.SNXD_CLIENT_ID }}
solsta_client_secret: ${{ secrets.SNXD_CLIENT_SECRET }}
In Solsta, an environment will typically consist of multiple repositories (independent components) of your game or software product. For example, a “daily-dev” environment could consist of unique iterations of each of the following repositories
When the Solsta Dekstop Application installs this environment on machines, it will re-create the folder structure and files for each repository into a single user-specified installation directory. This means there must not be any overlap between files across repositories. If you want the client to re-create a specific sub-directory for a repository, then you must specify the proper directory when deploying releases within that repository.
For example, when deploying releases to a “mods” repository, you can specify up to the /mods/ folder in the “Working Directory” field of the Solsta Deploy Step. This will make the Solsta Desktop App re-create the structure of the the /mods/ folder as seen below:
If you prefer the Solsta Desktop App to re-create a “mods” folder instead, then you will need to specify the parent directory containing “mods” when you deploy. For example:
You can go as far up your directory tree as you need during deployment to have the Solsta Desktop App re-create the folder structure for each repository. You will need to make sure files and folders specific to the repository are isolated. Options for excluding or including specific sub-directories are upcoming.
In the promote snippet below, custom CI/CD variables are defined for the following:
Note that the values for product, environment and repository are case-sensitive. This action will promote the release currently assigned from the source Product, Environment and Repository to the target Product, Environment and Repository. If the target environment has an update path count value greater than zero, the process will automatically create delta update paths within the target Environment and Repository as part of the promotion step.
steps:
- name: Promote a Release from Dev to QA
uses: snxd/deploy-github-promote-action@v2
with:
console_version: '6.1.2.84'
scripts_version: '3.7.30
source_product: 'llamacraft'
source_environment: 'dev-nightly'
source_repository: 'game-client'
target_product: 'llamacraft'
target_environment: 'qa-internal'
target_repository: 'game-client'
solsta_client_id: ${{ secrets.SNXD_CLIENT_ID }}
solsta_client_secret: ${{ secrets.SNXD_CLIENT_SECRET }}
The Solsta Configure Launch Files action manages which files are launched by the client for a specified environment. In the configure launch files snippet below, custom CI/CD variables are defined for the following:
(“entry name” “path” “arg1 arg2 …”)
See the example below for more details.
Upcoming: How does the Solsta Desktop Client handle launch buttons
Launch Macros and macOS Executables
steps:
- name: Launch Files Configuration
uses: snxd/deploy-github-launchfiles-action@v2
with:
console_version: '6.1.2.84'
scripts_version: '3.7.30'
target_product: 'llamacraft'
target_environment: 'dev-nightly'
solsta_client_id: ${{ secrets.SNXD_CLIENT_ID }}
solsta_client_secret: ${{ secrets.SNXD_CLIENT_SECRET }}
launch_file1: '("Launch Game Server" "{installDirectory}/binaries/system/server.exe" "--debug --token={custom_variable}")'
launch_file2: '("macOS sample" "/usr/bin/open" "{installDirectory}game_prereq.pkg")'
launch_file3: '("Entry Name 3" "/path/to/exec" "arg1 arg2 ...")'