Skip to content

Commit

Permalink
Finished refactoring tests
Browse files Browse the repository at this point in the history
  • Loading branch information
Shane Brown committed Sep 12, 2023
1 parent 592310d commit ec96899
Show file tree
Hide file tree
Showing 2 changed files with 202 additions and 523 deletions.
297 changes: 11 additions & 286 deletions tests/test_validation/test_validation_run.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,21 +5,17 @@


def test_step_run_artifacts_valid():
config = {
'steps': {
'build-run': {
'run': {
'image': 'mytest-reg/buildrunner-test',
'artifacts': {
'bogus/path/to/artifacts/*': {
'type': 'zip',
'compression': 'lzma'
}
}
},
},
}
}
config_yaml = """
steps:
build-run:
run:
image: mytest-reg/buildrunner-test
artifacts:
bogus/path/to/artifacts/*:
type: zip
compression: lzma
"""
config = yaml.load(config_yaml, Loader=yaml.Loader)
errors = validate_config(**config)
assert errors is None

Expand Down Expand Up @@ -56,274 +52,3 @@ def test_push_invalid():
errors = validate_config(**config)
assert isinstance(errors, Errors)
assert errors.count() == 1


def test_push_full():
config_yaml = """
# Optional buildrunner configuration syntax version
version: 2.0
steps:
my-build-step:
# Optional step dependency definition to specify which steps need to be processed before this step.
# The `version` must be present and set to `2.0` or higher for buildrunner to utilize the step dependencies list.
# An buildrunner error will occur if `depends` is present but `version` is missing or value is lower than `2.0`.
depends:
- test-step
- validation-step
run:
# xfail indicates whether the run operation is expected to fail. The
# default is false - the operation is expected to succeed. If xfail
# is true and the operation succeeds then it will result in a failure.
xfail: False
# A map of additional containers that should be created and linked to
# the primary run container. These can be used to bring up services
# (such as databases) that are required to run the step. More details
# on services below.
services:
service-name-1: <service config>
service-name-2: <service config>
# The Docker image to run. If empty the image created with the 'build'
# attribute will be used.
image: <the Docker image to run>
# The command(s) to run. If omitted Buildrunner runs the command
# configured in the Docker image without modification. If provided
# Buildrunner always sets the container command to a shell, running the
# given command here within the shell. If both 'cmd' and 'cmds' are
# present the command in 'cmd' is run before the commands in the 'cmds'
# list are run.
cmd: <a command to run>
cmds:
- <command one>
- <command two>
# A collection of provisioners to run. Provisioners work similar to the
# way Packer provisioners do and are always run within a shell.
# When a provisioner is specified Buildrunner always sets the container
# command to a shell, running the provisioners within the shell.
# Currently Buildrunner supports shell and salt provisioners.
provisioners:
shell: path/to/script.sh | [path/to/script.sh, ARG1, ...]
salt: <simple salt sls yaml config>
# The shell to use when specifying the cmd or provisioners attributes.
# Defaults to /bin/sh. If the cmd and provisioners attributes are not
# specified this setting has no effect.
shell: /bin/sh
# The directory to run commands within. Defaults to /source.
cwd: /source
# The user to run commands as. Defaults to the user specified in the
# Docker image.
user: <user to run commands as (can be username:group / uid:gid)>
# The hostname assigned to the run container.
hostname: <the hostname>
# Custom dns servers to use in the run container.
dns:
- 8.8.8.8
- 8.8.4.4
# A custom dns search path to use in the run container.
dns_search: mydomain.com
# Add entries to the hosts file
# The keys are the hostnames. The values can be either
# ip addresses or references to service containers.
extra_hosts:
"www1.test.com": "192.168.0.1"
"www2.test.com": "192.168.0.2"
# A map specifying additional environment variables to be injected into
# the container. Keys are the variable names and values are variable
# values.
env:
ENV_VARIABLE_ONE: value1
ENV_VARIABLE_TWO: value2
# A map specifying files that should be injected into the container.
# The map key is the alias referencing a given file (as configured in
# the "local-files" section of the global configuration file) or a
# relative path to a file/directory in the build directory. The value
# is the path the given file should be mounted at within the container.
files:
namespaced.file.alias1: "/path/to/readonly/file/or/dir"
namespaced.file.alias2: "/path/to/readwrite/file/or/dir:rw"
build/dir/file: "/path/to/build/dir/file"
# A map specifying cache directories that are stored as archive files on the
# host system as `local cache key` and extracted as a directory in
# the container named `docker path`. The cache directories are maintained
# between builds and can be used to store files, such as downloaded
# dependencies, to speed up builds.
# Caches can be shared between any builds or projects on the system
# as the names are not prefixed with any project-specific information.
# Caches should be treated as ephemeral and should only store items
# that can be obtained/generated by subsequent builds.
#
# Two formats are supported when defining caches.
# 1) RECOMMENDED
# <docker path>:
# - <local cache key A>
# - <local cache key B>
#
# Restore Cache:
# This format allows for prefix matching. The order of the list dictates the
# order which should be searched in the local system cache location.
# When an item isn't found it will search for archive files which prefix matches
# the item in the list. If more than one archive file is matched for a prefix
# the archive file most recently modified will be used. If there is no
# matching archive file then nothing will be restored in the docker container.
#
# Save Cache:
# The first local cache key in the list is used for the name of the local
# cache archive file.
#
# 2) <local cache key>: <docker path> (backwards compatible with older caching method, but more limited)
#
caches:
# Recommended format.
<docker path>:
- <local cache key A>
- <local cache key B>
"/root/.m2/repository":
# Buildrunner will look for a cache that matches this cache key/prefix,
# typically the first key should be the most specific as it is the closest match
# Note that this first key will also be used to save the cache for use across builds or projects
- m2repo-{{ checksum("pom.xml", "subproj/pom.xml") }}
# If the first cache key is not found in the caches, use this prefix to look for a cache that may not
# be an exact match, but may still be close and not require as much downloading of dependencies, etc
# Note that this may match across any cache done by any build on the same system, so it may be wise to
# use a unique prefix for any number of builds that have a similar dependency tree, etc
- m2repo-
# If no cache is found, nothing will be extracted and the application will need to rebuild the cache
# Backwards compatible format. Not recommended for future or updated configurations.
<local cache key>: <docker path>
maven: "/root/.m2/repository"
# A map specifying ports to expose, this is only used when the
# --publish-ports parameter is passed to buildrunner
ports:
<container port>: <host port>
# A list specifying service containers (see below) whose exposed
# volumes should be mapped into the run container's file system.
# An exposed volume is one created by the volume Dockerfile command.
# See https://docs.docker.com/engine/reference/builder/#volume for more
# details regarding the volume Dockerfile command.
volumes_from:
- my-service-container
# A list specifying ssh keys that should be injected into the container
# via an ssh agent. The list should specify the ssh key aliases (as
# configured in the "ssh-keys" section of the global configuration
# file) that buildrunner should inject into the container. Buildrunner
# injects the keys by mounting a ssh-agent socket and setting the
# appropriate environment variable, meaning that the private key itself
# is never available inside the container.
ssh-keys:
- my_ssh_key_alias
# A map specifying the artifacts that should be archived for the step.
# The keys in the map specify glob patterns of files to archive. If a
# value is present it should be a map of additional properties that
# should be added to the build artifacts.json file. The artifacts.json
# file can be used to publish artifacts to another system (such as
# Gauntlet) with the accompanying metadata. By default artifacts will be
# listed in the artifacts.json file; this can be disabled by adding the
# ``push`` property and set it to false.
#
# When archiving *directories* special properties can be set to change
# the behavior of the archiver. Directories by default are archived as
# gzip'ed TARs. The compression can be changed by setting the
# ``compression`` property to one of the below-listed values. The
# archive type can be changed by setting the property ``type:zip``.
# When a zip archive is requested then the ``compression`` property is
# ignored. If the directory tree should be gathered verbatim without
# archiving then the property ``format:uncompressed`` can be used.
#
# NOTE: Artifacts can only be archived from the /source directory using
# a relative path or a full path. Files outside of this directory will
# fail to be archived.
artifacts:
artifacts/to/archive/*:
format: uncompressed
type: tar
compression: bz2
push: True
property1: value1
property2: value2
# Whether or not to pull the image from upstream prior to running
# the step. This is almost always desirable, as it ensures the
# most up to date source image.
# NOTE: If the image was created from a 'push' or 'commit' earlier in
# this ``buildrunner.yaml`` then this will default to false
pull: True
# Specify a different platform architecture when pulling and running images.
# This is useful if you are running an image that was built for a different architecture
# than what buildrunner is running on, such as using a linux/arm64/v8 Apple M1 architecture
# development machine to run or test an image built for linux/amd64 architecture.
platform: linux/amd64
# systemd does not play well with docker typically, but you can
# use this setting to tell buildrunner to set the necessary docker
# flags to get systemd to work properly:
# - /usr/sbin/init needs to run as pid 1
# - /sys/fs/cgroup needs to be mounted as readonly
# (-v /sys/fs/cgroup:/sys/fs/cgroup:ro)
# - The security setting seccomp=unconfined must be set
# (--security-opt seccomp=unconfined)
# If this is ommitted, the image will be inspected for the label
# 'BUILDRUNNER_SYSTEMD'.
# If found, systemd=true will be assumed.
systemd: True
# Docker supports certain kernel capabilities, like 'SYS_ADMIN'.
# see https://goo.gl/gTQrqW for more infromation on setting these.
#cap_add: 'SYS_ADMIN'
#<or>
cap_add:
- 'SYS_ADMIN'
- 'SYS_RAWIO'
# Docker can run in a privileged mode. This allows access to all devices
# on the host. Using privileged is rare, but there are good use cases
# for this feature. see https://goo.gl/gTQrqW for more infromation on
# setting these.
# Default: false
privileged: True
# The post-build attribute commits the resulting run container as an
# image and allows additional Docker build processing to occur. This is
# useful for adding Docker configuration, such as EXPOSE and CMD
# instructions, when building an image via the run task that cannot be
# done without running a Docker build. The post-build attribute
# functions the same way as the 'build' step attribute does, except
# that it prepends the committed run container image to the provided
post-build: path/to/build/context
# <or>
# FIXME - not tested yet
# post-build:
# dockerfile: |
# EXPOSE 80
# CMD /runserver.sh
# A list of container names or labels created within any run container
# that buildrunner should clean up. (Use if you call
# 'docker run --name <name>' or 'docker run --label <label>' within a run container.)
containers:
- container1
- container2
"""
config = yaml.load(config_yaml, Loader=yaml.Loader)
errors = validate_config(**config)
assert errors is None
Loading

0 comments on commit ec96899

Please sign in to comment.