Advanced Configuration

Advanced Strider Configuration

Strider will work as a great CI/CD solution out of the box, but if you really want to get the most out of Strider, you're going to want to deploy more advanced means of configuring it.

In this guide, we'll cover:

• getting Strider to use Docker to process jobs
• configuring your jobs with a strider.json file.
• tuning Strider performance

Docker

Strider comes with 2 runners. A runner is the module that processes your jobs.

By default, the simple runner is used. The simple runner will process a job on the server on which Strider runs. So it uses the active operating system and just runs all commands directly in the shell.

This is great, because it is easy to set up and understand. However, your jobs will be affected by the environment set up by your operating system and it can be hard to fully control your testing environment.

This is where Docker comes into play. Setting up Docker on your server is out of the scope of this guide. So we're going to assume that you've already managed to set it up.

Installation

To enable Docker support in Strider, go to Admin → Plugins and Install the Docker Runner plugin.

That's it.

Usage

You can now go into the settings for one of your projects, go to the Plugins section and change the runner to Docker. Then you can go to the Runner: Docker section and configure the runner.

The default settings will usually work fine if Docker is running on the same host as Strider and if your project works fine with the default Docker image provided by Strider.

In case the default image doesn't work for you, you're going to want to publish your own Docker image. For an image to work right with Strider, certain mechanics need to be implemented in the container. To get a working image that interacts fine with Strider, you should fork an existing image and work from there:

• https://github.com/Strider-CD/strider-docker-slave - The default Docker image Strider uses
• https://github.com/fairmanager/strider-docker-slave - An image optimized for testing with NodeJS 4

The strider.json file

Everything that you can set through the Strider web interface can also be controlled through a file named strider.json, which you put directly into your repository. This should be the preferred way to configure Strider, as it keeps CI/CD settings within the repository; giving you all the benefits of VCS and simplifying configuration.

If you're planning on using the strider.json approach, it is recommended to import new projects into Strider using the custom project type. This ensures that no default plugins are loaded, which would only interfere with your strider.json.

Let's look at an example first:

{
	"runner": {
		"id": "docker",
		"config": {
			"image": "fairmanager/strider-docker-slave"
		}
	},
	"merge_plugins": true,
	"plugins": [
		{
			"id": "node",
			"enabled": true,
			"showStatus": true,
			"config": {
				"test": "npm test",
				"caching": "strict",
				"runtime": "whatever",
				"fork": "Node.js"
			}
		},
		{
			"id": "custom",
			"enabled": true,
			"showStatus": true,
			"config": {
				"shell": "bash",
				"prepare": ".scripts/prepare.sh --<%= ref.branch %>",
				"deploy": ".scripts/deploy.sh --<%= ref.branch %>"
			}
		}
	]
}

Now let's go through this step-by-step.

runner

The first section is the runner section. Here we tell Strider what job runner to use. We can pick the simple runner, where the id is simple-runner, or we can use Docker (which we want) and set the id to docker.

Note: If you don't specify a runner section at all, Strider will default to the simple runner.

We can then provide additional configuration options to the runner. These are the options you would usually set on the Runner: Docker section of your project configuration. As seen in the example, this is the perfect place to set your Docker image.

Note: If Strider is running on Windows, the default Docker host setting will not work for you, as Strider will attempt to connect to a UNIX socket to connect to Docker. It is advised to run Docker in an environment where DOCKER_HOST is set to tcp://localhost:2375. Setting the host in the strider.json should be discouraged.

merge_plugins

If you set this directive to false, the complete configuration made through the web UI is discarded and only the configuration set through the strider.json is respected.

You'll rarely want to do this, as certain configurations are best left in the web UI and you want those to be merged with those made through strider.json. A common use case would be setting secret environment variables through the Environment plugin in the web UI.

Regardless of if you want this to be true or false, it is recommended to explicitly set this in your strider.json, as a change in the default behavior might have a major impact on your jobs!

plugins

Here you'll list all the Strider plugins you're going to use in your jobs.

id

Most importantly, you'll identify each plugin by the id value. This can be found in the plugin's package.json file. For example, in the strider section of strider-custom. Every Strider plugin has a strider section in their package.json. It's also important to note that any referenced plugin first needs to be installed manually through the web UI.

enabled

I really can't see any reason to set this to anything other than true, but make sure to do that.

showStatus

The author is not clear on the specifics of this directive. It is recommended to set it to true.

config

The configuration of each plugin is specific to the plugin itself and is highly unlikely to be documented.

In the example above, we see the important directives for 2 plugins: node and custom.