Steps

A step is the core building block of a Microtica pipeline. By chaining steps together, you build pipelines that automate your entire software delivery process.

Microtica has two types of pipeline steps:

• Generic steps
• Built-in steps

Generic steps

Generic steps give you full control over what a step does, so you can define its instructions precisely.

steps:
  MyGenericStep:
    image: node:latest
    title: Build my NodeJS app
    commands:
      - npm install
      - npm test

This step definition has:

• image – the Docker image that defines the runtime environment
• title (optional) – a step description
• commands – a list of commands to be executed in this step

Here, you use the latest version of Node.js as the runtime environment and run a set of npm commands.

In the same way, you can define a Go runtime environment and compile the code:

steps:
  MyGoStep:
    image: golang:latest
    commands:
      - go build

Built-in steps

Built-in steps are steps Microtica provides for actions that are common in CI/CD pipelines, such as building and pushing Docker images, running Terraform scripts, or sending Slack messages.

The example below uses a built-in step of type docker-push that builds and pushes a Docker image to a specified registry.

steps:
  PushDockerImage:
    type: docker-push
    image_name: microtica/my-app
    tag: v0.1.0
    registry: my-registry

This step definition has:

• type – the step type
• image_name – the name of the image to be pushed
• tag – the tag identifier for the image
• registry – the name of the registry, created within Microtica, to be used

Notice that you don't specify a runtime or any custom commands for this step. Everything happens automatically behind the scenes.

Each built-in step, such as docker-push, has its own reference page with the full parameter list.

Input parameters

Input parameters let a step accept input data to use during execution. In generic steps, you can define any number of input parameters.

Use parameters when you want to:

• parametrize the way your pipeline works
• avoid hard-coding within the step execution logic
• avoid storing sensitive information within the pipeline YAML using pipeline variables

Here is an example of passing a custom parameter to a step:

steps:
  BuildApp:
    image: node:latest
    commands:
      - echo "Build my service: ${service_name}"
    parameters:
      service_name: "User Service"

You can reference the service_name parameter in the commands section through standard Unix syntax, ${service_name}.

Sharing state between steps

Microtica shares state between steps automatically, so you don't have to manage or maintain it yourself.

Every step in the pipeline shares the same directory state with the others. Files generated in the current step are automatically available to all following steps in the execution order.

This is handy when you design a pipeline with multiple steps that need the same state. A good example is compiling your code in one step and running tests against the compiled code in another.

Artifacts

Sharing state is useful when you want the state to persist between steps. When you want a step's output available outside the pipeline, use artifacts instead.

Here is an example of producing an output artifact, my_artifact:

steps:
  BuildNodeApp:
    image: node:latest
    commands:
      - npm install
      - npm run build
    artifacts:
      files:
        # wildcard are also supported in the path (e.g. /build/*.js)
        my_artifact: /build/

In this case, the entire content of the build folder is packaged, zipped, and stored on secure blob storage.

You can download artifacts from the GUI for each pipeline execution. If more than one artifact is declared, you choose which one to download.

Microtica also provides built-in support for Docker and JSON artifacts. To learn more about all supported artifact types, see Artifacts.

Next steps

• Clone a repository with git-clone
• Build and push images with docker-push
• Store and reuse artifacts