The Solsta Plugin for Jenkins adds various build steps that use the Solid State Networks console tools and Manifest API service to deploy and promote releases within the Solsta ecosystem. Deploying consists of converting and uploading raw files (assets) to a bucket or CDN in order to make releases available for download by Solsta desktop clients. The plugin supports both Jenkins freestyle and pipeline projects (see below for details).
Article updated February 15th, 2023 for Solsta Jenkins Plugin version 1.30 or later.
In order for a Jenkins Node to execute a build step from this plugin, it must have the following components installed:
Within your Jenkins server, use the “advanced installation” instructions from Managing Plugins to upload and install the Solsta plugin .hpi file.
If you are updating the plugin from a previous version, we recommend uninstalling the existing plugin first. Uninstalling a plugin will not permanently remove its steps from any of your existing projects.
After the uninstall, upload and install the latest Solsta Plugin for Jenkins .hpi file and then restart your Jenkins server. This is required when installing new plugins and it ensures your server is using the latest version. We recommend reviewing any projects using build steps from the Solsta plugin before executing any new builds or pipelines.
The Solsta Plugin allows for the creation of Products, Environments and Repositories within the Solsta deployment database during the deployment step, however, those objects can also be created in the Solsta Desktop Application. Please see the articles below for more information:
The Solsta Plugin provides four new options to use as build steps in Jenkins. Each build step requires a Client ID and Client Secret from Solid State Networks. These credentials 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 Solsta Deploy step deploys (uploads) a new release to the server, bucket or CDN associated with the specified Environment. When creating a Build Step, select Solsta Deploy from the dropdown and then fill out the following fields.
How to Manage Files from Multiple Repositories in the Same Environment
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.
The screenshot above shows configuring the plugin in a Jenkins “Freestyle” project. If your Jenkins project is a “Pipeline” type, you can use the Pipeline Syntax section of Jenkins to generate a snippet for each of the steps available from this plugin. In the Sample Step dropdown, each step from the plugin will be pre-pended by ssn_.
On the Snippet Generator page, select your desired Sample Step and fill out each of the fields. Afterwards, scroll down and click the Generate Pipeline Script button:
From here, you can copy and paste the snippet into your Pipeline deployment script. Of course, you can update it with any dynamic values or environment variables as necessary.
The Solsta Promote step promotes the latest release from a source Product, Environment and Repository to a target Product, Environment and Repository. If the source and target Environments have different source location values (buckets or origin servers), the promote step will automatically copy all necessary files from the source location to the target location as part of the promotion step.
Also, if the target environment has an update path count value greater than zero, the promote step will automatically create delta update paths within the target Environment and Repository as part of the promotion step.
The Solsta Configure Launch Files step manages which files are launched by the client for a specified environment. Choose values for the Product and Environment fields first, then configure multiple launch entries for that environment.
Follow the steps below to add, edit or delete launch entries for an environment. Remember to save your configuration and run the build/pipeline containing the Solsta Configure Launch Files step in order for your changes to take effect.
Add a Launch Entry
Edit a Launch Entry
Delete a Launch Entry
The Solsta Cleanup step cleans up (deletes) old, unused release data from the server, bucket or CDN associated with the specified Environment. Deleting releases is upcoming functionality in the Solsta Desktop Application.
© Solid State Networks, LLC. All Rights Reserved.
Let us know what build system you are using.
"*" indicates required fields