A Razorops Pipeline is the name of the code repository for which it automates workflows, tests and deployments. You can find a list of pipelines in the dashboard.
You can optionally configure settings, secrets, and team members who may have access to a pipeline afterward.
After a source code repository on Github, Bitbucket or Gitlab is authorized and added as a pipeline, every code change triggers a build and automated tests in a clean container configured for your requirements.
Runner defines an execution environment where your workflows and tasks are run. It is a virtual machine hosted by Razorops with an agent application installed. Currently we provide Ubuntu Linux and Docker VM environments having common build tools preinstalled.
We offer built-in support for Linux and Docker-based pipelines currently. Support for MacOS, Windows, Android based runner is coming soon.
A Workflow is a pipeline run triggered by a code change, webhook or API call. It's a set of rules for defining a collection of tasks and their execution order in a special file (
.razorops.yaml). Workflows are implemented as a directed acyclic graph (DAG) of tasks for flexibility. A workflow consists of multiple tasks, each of which will be run in a defined order. If a task fails, then the workflow is considered failed and the following tasks will not be started.
An instance of your workflow that runs tasks defined in the YAML spec file. It's an automated process and executes independently of each other having their own logs, events, workspace and temporary directories.
A workspace is a working directory shared by all steps in a task. A workspace stores data unique to the task, which may be needed in downstream tasks. In the beginning of a pipeline, source code is checked out to the workspace. The command for every step bootstraps in the workspace. During a pipeline execution, the artifacts from a previous step will be available in future steps. The working directory is an ephemeral volume and will be cleaned out when a pipeline execution is finished.
It provides support for persisting and downloading files or directories between tasks in a workflow. For more details, see "Working with layers".
A task consists of multiple steps (shell commands), each of which will be run in order. If a step in a task fails, then the task is considered failed, and unless specified otherwise, the rest of the steps in the task will not be run.
A step is an individual process that can run commands or defined actions. A task configures one or more steps. Each step in a task executes on the same runner, allowing the actions in that task to share information using the filesystem.
Artifacts are the files created when you build and test your code and want to view after a workflow completes. For example, artifacts might include binary or package files, test results, screenshots, or log files. Artifacts are associated with the workflow run where they were created and can be used by another job or deployed. For more details, see "Using artifacts".
It helps to reduce runtime between subsequent workflow runs by caching external build dependencies or directories, like third-party libraries. If a task downloads dependencies from the internet, which can take a lot of time, we recommend to cache such dependencies on the first run and reuse for later runs. For more details, see "Caching dependencies".
Report helps to identify changes and visualize the test metrics easily without having to check the entire log and workflows history. It provides support for generating insights from Junit tests and HTML previews from coverage reports for most languages.