The Octo pipeline gives the ability to work both with an actual pipeline such as jenkins / github actions etc and locally on a machine

The pipeline consists of the following abbreviations:

• Backend - Some backend that can execute actions
• Action - An action that needs to happen on the backend, such as consume, build
• Pipeline - A set of actions that run on different backends
• Workspace - A set of pipelines with dependencies between them

Each component above can be controlled via the octo executable

The pipeline requires Python 3.8+

In order to install octo-pipeline, you can install it directly from pypi:

pip3 install octo-pipeline-python

Do notice that we use "extras" for our pipeline, each sub library of the pipeline is a specific backend that you can choose to install or not Choosing "all" will install the pipeline along with all the backends

pip3 install install octo-pipeline-python[all]

Once the above is done, the pipeline should be installed along with all the dependencies on the machine

You can remove the pip.conf if you don't want to use the index anymore

Auto-completion for CLI arguments can be enabled as described in the argcomplete#zsh-support package which is part of the requirements for octo.

Source the following in your .bashrc or .zshrc:

eval "$(register-python-argcomplete octo)"

The pipeline is defined by a yaml file and an optional yaml parameters file

The main pipeline yaml file can look for example as following

name: curlpp
scm: https://github.com/jpbarrette/curlpp.git
version: 0.8.1
maintainers:
  - jpbarrette
pipeline:
  - source:
      backend: git
      surroundings:
        - jenkins
        - local
  - consume:
      backend: conan
      surroundings:
        - jenkins
        - local
  - build:
      backend: conan
      surroundings:
        - jenkins
        - local
  - install:
      backend: conan
      surroundings:
        - local
  - package:
      backend: conan
      surroundings:
        - jenkins
        - on-demand

This will define a pipeline for the repository, and will run the actions sequential

Each action is defined by a set of backends it needs to run on

Each backend can define the actions it supports accordingly

We can also supply a "name" to the action such that:

  - build:
      name: build-win
      backend: golang
      surroundings:
        - jenkins
        - on-demand
  - build:
      name: build-linux
      backend: golang
      surroundings:
        - jenkins
        - on-demand

So that we can support multiple actions of the same type for different use cases

Lasty, each action can define on which surroundings it can run on

Currently the supporting surroundings are

• jenkins
• local
• on-demand
• workspace

Along with the above file, you can define parameters for different backends by either specifiying backends key on the pipeline yaml file, or defining a backends.yml file

The backends yaml file can look as follows

git:
  head: v0.8.1
conan:
  artifactory: https://jfrog.com
  configurations:
    - debug
    - release

For each backend you will define a set of parameters that may or may not be used

If a specific action settings need to apply, or settings for a platform, this can be done as follows:

golang:
  actions:
    build-win:
      - platform: linux
        settings:
          env:
            GOOS: windows
            GOARCH: amd64
            GO111MODULE: "on"
            CC: i686-w64-mingw32-gcc
            CXX: i686-w64-mingw32-g++
          entrypoints:
            - cmd/provision_win.go
            - cmd/deprovision_win.go

Notice that we can use "build" or "build-win" as action type or action name to define settings for our specific action Those settings are only applied on the linux platform

Once the pipeline is installed, you can either clone a repository of an existing pipeline and work on ur own

Or u can use the pipeline to help you out

For example, if you wish to work "curlpp" existing pipeline, you could perform the following command

octo pipeline init --org=pas --name=curlpp

The above will try and find inside pas organization the repository, check if it has a pipeline and clone it accordingly

Once the above is done, you can execute the pipeline for that component by running

octo pipeline execute

This will trigger the pipeline defined for the component

You could also run specific actions by running the following

octo pipeline execute-action consume

And lastly, you could run the pipeline step by step and control the flow on ur own

This can be done by using the following commands in a queue style

octo pipeline step next
octo pipeline step previous
octo pipeline step current
octo pipeline step execute
octo pipeline step clean
octo pipeline step reset

All of the above will control each step you are running on

All of the pipeline actions can be listed with --help:

usage: octo.py pipeline [-h]
                            {init,execute,describe,describe-actions,clean,name,version,build_number,scm,execute-action,clean-action,step}
                            ...

positional arguments:
  {init,execute,describe,describe-actions,clean,name,version,build_number,scm,execute-action,clean-action,step}
    init                Initializes the pipeline backends and working directory
    execute             Executes the entire pipeline actions
    describe            Prints out a detailed description of the pipeline
    describe-actions    Prints out the list of actions on the pipeline
    clean               Cleans up all the actions that ran so far
    name                Prints out the name of the pipeline
    version             Prints out the version of the pipeline
    build_number        Prints out the build number of the pipeline
    scm                 Prints out the scm of the pipeline
    execute-action      Executes a specific type of action
    clean-action        Cleans up a specific type of action
    step                Step execution of the pipeline

optional arguments:
  -h, --help            show this help message and exit

You can execute specific backend operations such as authentication

The backend is responsible for keeping the state of authentication if working via the CLI

If you wish to authenticate to a backend, you may run

octo backends conan authenticate --username=john --secret=john --certificate="/path/to/cert"

You may also add a target argument if you wish to authenticate to a specific resource in the backend

You may execute other operations on the backed as described in the help

usage: octo backends conan [-h] {authenticate,describe,working-dir,get} ...

positional arguments:
  {authenticate,describe,working-dir,get}
    authenticate        Authenticate to a backend
    describe            Prints out a description of the backend
    working-dir         Prints out the working directory of the backend
    get                 Gets a specific key from the context of the backend

optional arguments:
  -h, --help            show this help message and exit

A workspace is a set of pipelines that can run in certain order

The workspace is defined by a yaml that can look similar to the following

name: coolspace
scm: git@github.com
organizations:
  - coolorg
workspace:
  - 3rdparties:
    - curlpp
    - nlohmann-json
    - stduuid
    - aws-sdk-cpp
  - core:
    - graphics
    - logger

Where you can define which organizations in the scm to look for the repo

And define the workspace layout, and who depends on who

Along with that, you may also define settings that can propogate to the pipelines in a workspace level

Those settings can be divided by system

The workspace can be initialized by running the following command

octo workspace init --org=pas --name=coolorg-ws

This will try to find the workspace and clone it, and along with it, clone the entire actual workspace definition

If you do not wish to also sync the workspace on init, add --no-sync

And you can later run the sync yourself with

octo workspace sync

Afterwards, you may choose to run any of the following commands

octo workspace execute all
octo workspace execute-action all build
octo workspace execute 3rdparties
octo workspace execute graphics
octo workspace execute-action graphics build
octo workspace clean all
octo workspace clean-action all build
octo workspace clean 3rdparties
octo workspace clean graphics
octo workspace clean-action graphics build
octo workspace describe

The above commands can execute the entire workspace pipeline, specific pipeline based on the workspace yml, or cleanup accordingly