Work flow

Roberto divides the continuous integration process into smaller “tasks”, which are listed by rob --help and which are defined in roberto/tasks.py:

  • {name} will {endsentence}

  • {name} will {endsentence}

  • {name} will {endsentence}

  • {name} will {endsentence}

  • install-requirements depends on setup-testenv and will install all requirements, including tools used by Roberto.

  • lint-static depends on install-requirements, sanitize-git, write-version and will run static linters.

  • build-inplace depends on install-requirements, sanitize-git, write-version and will build software in-place and update environment variables.

  • build-packages depends on install-requirements, write-version and will build software package(s).

  • deploy depends on install-requirements, build-packages and will run all deployment tasks.

  • lint-dynamic depends on build-inplace and will run dynamic linters.

  • test-inplace depends on build-inplace and will run tests in-place.

  • upload-coverage depends on test-inplace and will upload coverage reports, if explicitly enabled in config.

  • build-docs depends on install-requirements, build-inplace, write-version and will build documentation.

  • quality depends on lint-static, test-inplace, upload-coverage, lint-dynamic, build-docs and will run all quality assurance tasks: linting and in-place testing.

  • upload-docs depends on install-requirements, build-docs and will upload documentation.

  • robot depends on quality, upload-docs, deploy and will run all tasks, except nuke_virtual_env.

When rob is executed without arguments, the quality task is executed, which runs all the tests related to the in-placed build. You may provide one or more task names as positional command-line arguments to change this behavior. The robot task is a more complete test and runs all tasks except for nuke-testenv, so also including the packaging.

The tasks sanitize-git, setup-testenv, install-requirements and nuke-testenv are less configurable than the other tasks. They take care of a proper development environment for the remaining tasks, except for nuke-testenv which does exactly the opposite.

The other tasks are more configurable through .roberto.yml. In this file, you specify which software packages need to be built and which tools should be used in each task. More details can be found in Configuration.

When Roberto starts, it will also run git describe --tags to determine the current version. It is assumed that git tags are complete semantic version numbers. The expected format of a tag is just three numbers separated by dots, not prefixed with a v. Suffixes for alpha (dev), beta (test) and post releases are supported in line with PEP404. Roberto will fail when the last tag does not follow these conventions. The version information can be used in all tasks. The most prominent one is write-version, which can write updated version files.

For development purposes, it is often sufficient to run rob quality to perform all code quality checks or rob build-inplace to prepare a working in-place compilation. The latter will also generate a file activate-*-dev-*.sh, which can be sourced to load all the environment variables that will activate the in-place build for further testing.