mirrord for CI
How to use mirrord in a CI environment with `mirrord ci` commands.
mirrord can be used to greatly speed up CI runs by enabling testing against a shared staging environment without interrupting it. With mirrord for CI, you're able to keep your staging environment working, while also running your batch of end-to-end and other automated tests. The local app runs in the context of the targeted app that's deployed in your staging cluster, so it gets access to traffic, files, and more, as if it's running in the cluster. This means there's no need to spin up a whole test environment for a CI run, then spin it down when it's done.
While running regular mirrord exec can be made to work for this purpose, it requires some finagling to get right, such as wrapping mirrord exec in some other command that would start it as a background process. The mirrord ci start command is more appropriate for this use case, since it starts your app and mirrord as background processes, allowing you to then run tests while your app is running in the background and connected to the cluster.
Prerequisites
Minimum mirrord CLI version
3.181.0.The CI runner must be able to access the Kubernetes cluster in which you want to test.
Kubernetes requirements
The CI runner must be able to access the Kubernetes cluster where the service you want to target is deployed, otherwise mirrord won't work. You'll need a kubeconfig in the CI runner that points to the target's cluster, and has the appropriate authentication.
It's recommended that you create a Kubernetes service account for the CI runner.
For mirrord for Teams users
To use mirrord ci with mirrord Operator, you'll need to generate a CI API key and store it as a secret environment variable. This will prevent your usage of mirrord in CI from expending your seats, which are counted using a machine-based ID.
You can get this key by running the command:
mirrord ci api-keyCopy it and save it as the secret environment variable MIRRORD_CI_API_KEY in your CI.
Starting a mirrord CI session
The mirrord ci start command functions very much like the mirrord exec command, meaning that it can take the same arguments, such as using a configuration file with --config-file, setting a target with --target, etc.
An example of starting a mirrord for CI session with
npm run(you can run anything, it's not limited tonpm):
You can start multiple mirrord for CI sessions during a single CI job by running 'mirrord ci start' more than once.
The mirrord for CI session should now be running in the background, and you can run the tests. These tests should target the deployed service (the app running in your staging cluster, for example), and mirrord will intercept the traffic and redirect it to the local app (the one running in the background in the CI runner with mirrord).
Application logs
By default, stdout and stderr outputs from your application are saved to a file in the OS' temporary directory (e.g. /tmp/mirrord). A directory is created based on the name of the binary you're running with mirrord, for example:
You can change this directory with the config ci.output_dir:
When running mirrord ci start --config-file mirrord.json, stdout and stderr outputs will be saved in the specified directory, e.g.:
Stopping a mirrord CI session
After the tests are done, you should stop the mirrord CI session using mirrord ci stop. It's recommended that you do it, even if you won't be running mirrord for another service in this CI runner.
Stopping a mirrord CI session:
mirrord will stop running itself, and the local app.
Last updated
Was this helpful?