Provisioning using CIJOE

cijoe does not have a pre-defined pattern or setup for provisioning your test-target(s). However, since cijoe already knows about your test-target via the Environment Definition and it has Bash-modules for common tasks, then one can conviently write a script taking take of provisioning tasks before Running Testplans.

That is, to do things like following examples.

Command Example(s)

Build your project, producing a deb-package, on your dev box, then transfer it to your test-target for installation:

# Build on your *dev box*
make deb

# Transfer and install on your *test-target**
cij.push "my_project.deb"
cij.cmd "dpkg -i my_project.deb"

Transfer project-source to test-target, in order to build and install on the test-target itself:

cij.push "my_project_source.tgz"
cij.cmd "tar xzf my_project_source.tgz"
cij.cmd "cd my_project_source && make && make install"

You can do the above by running the commands in the Interactive Shell as the cijoe shell as it has access to the cijoe modules and the environment definition. However, to avoid having to retype the same commands over and over, then you can it a small script to your workflow doing the above instead.

Scripting Snippet

Use the following snippet to give your script access to cijoe and the test-target described by the Environment Definition named

pushd $(cij_root) && source modules/ && source && popd


This snippet is mostly useful when adding cijoe to a build-system, or CI/CD pipelines, that is, in situations where you just want to run a command or two within the confines of the CI/CD system. For a more elaborate approach, see the Scripting Example.

Scripting Example

The following is an example of the common tasks one might be doing, during a regular development workflow/cycle: build, deploy, run, postprocess, and analyze the results.

In case your development tools can be instrumented from the command-line, then you can glue them together in a looks something like this:

#!/usr/bin/env bash
# Template workflow/provision script using CIJOE
SCRIPT=$(basename $0)
pushd $(cij_root) && source modules/ && popd

task_build() { "Bulding!"

task_deploy() { "Deploying!"

task_run() { "Running! E.g. invoking cij_runner..."

task_postprocess() { "Postprogressing! E.g. invoking cij_reporter, etc." "Invoke other tools for post-processing the testrun"

task_all() {
  task_build $@
  task_deploy $@
  task_run $@
  task_postprocess $@

task_help() {
  echo "Usage: ${SCRIPT} <command> <env>"
  echo "Commands:"
  echo "  build <env>           ; Build ${PROJECT} in <env> or for deployment to <env>"
  echo "  deploy <env>          ; Deploy ${PROJECT} to <env>"
  echo "  run <env>             ; Invoke test-runner for ${PROJECT} in <env>"
  echo "  postprocess <env>     ; Postprocess results from 'run'"
  echo "  all <env>             ; Do all the tasks above in/to/for <env>"

main() {

  case $task in
  "" | "-h" | "--help")

    if [[ ! -f "$env" ]]; then
      cij.err "Invalid env: '$env'"
      exit 1

    source "$env"
    task_${task} $@
    if [ $? = 127 ]; then
        echo "Error: '$task' is not a known task." >&2
        echo " Run '${SCRIPT} --help' for a list of known tasks." >&2
        exit 1

main $@

Here is what usage of such as script would look like:

./ --help
Usage: <command> <env>
  build <env>           ; Build foobar in <env> or for deployment to <env>
  deploy <env>          ; Deploy foobar to <env>
  run <env>             ; Invoke test-runner for foobar in <env>
  postprocess <env>     ; Postprocess results from 'run'
  all <env>             ; Do all the tasks above in/to/for <env>

The above is just an example of separating your workflow into tasks and using basic scripted commands to glue the tasks from different toolchains together. And adding to that, tying these tasks together for your project and utilization of test-targets. An infinite amount of ways of doing these sort of things exists, do whatever fits you and your projects.