Custom Test
Using custom images can be useful for installing in-house tooling and will run faster than installing these tools at runtime. However, it also has the operational overhead of maintaining the custom image.
Overview
This guide explains how you can use Signadot's Continuous Testing (CT) feature to run tests without using popular frameworks.
Running Tests as a Signadot Job
Running a test as a Signadot Job provides context awareness, meaning that if the sandbox referenced in the test is terminated, closed, or in any other failed state, the test will automatically fail. This makes the tests more reliable.
Create base image
# You can even use a lighter image, but make sure you have all deps you need
FROM ubuntu:latest
ENV HOME /root
WORKDIR $HOME
# Install basic tools
RUN apt-get update && \
apt-get install -y git wget && \
apt-get clean autoclean && \
rm -rf /var/lib/{apt,dpkg,cache,log}/
# Do more stuff ....
Create Job Runner Group
To start with Signadot CT, we need to create a Job Runner Group.
name: my-custom-runner
spec:
cluster: "@{cluster}"
labels:
env: "@{env}"
# Depending on your need, it can be a standard image, or a
# custom one you have built to suit your testing needs.
image: <image_registry>/<image_name>:tag
jobTimeout: 30m
scaling:
manual:
desiredPods: 1
podTemplate:
spec:
imagePullSecrets:
- name: your_registry
It's expected you to have already set up the registry where you are trying to push/pull the image from. For further reference you can check how to k8s pull image private
Create Job Specification
spec:
namePrefix: my-custom-job
runnerGroup: my-custom-runner
script: |
#!/bin/bash
set -e
# Clone the git repo
echo "Cloning repo"
git clone --single-branch -b "@{branch}" \
https://github.com/<org>/<repo>.git
# Run the tests.
# Optionally, make the artifacts available as a single compressed
# file if you'd like to upload them as a single artifact.
routingContext:
sandbox: "@{sandbox}"
uploadArtifact:
- path: your_project/artifact1
- path: your_project/artifact2