Skip to content

EmbedOps Build Reference

EmbedOps is designed to work with any number of build systems and facilitate and managed environment shared between development and CI/CD.

EmbedOps does this through a build abstraction layer which allows you to define pipeline steps in a shell script.

EmbedOps Templates follow a convention of placing all build steps inside of a root-level ci/ directory to allow easy addition of pipeline steps.

EmbedOps Build Files

Two files - ci/pipeline.sh and ci/pipeline.json are generated when you initialize your repository with EmbedOps via eo init.

$ ls ci/
pipeline.sh
pipeline.json

ci/pipeline.sh

The ci/pipeline.sh script iterates through build steps defined in the ci/pipeline.json file. This file is modified by an additive merge operation during eo add operations.

Because the pipeline.sh is only generated once, if you would like to add custom steps to your pipeline that are outside of the pipeline.json file, add them to the pipeline.sh script.

ci/pipeline.json

The pipeline.json file is a JSON file that defines the build steps for your project. The file is generated by eo init and modified by eo add operations.

{
  "steps": [
    "ci/arm-none-eabi-build.sh",
    "ci/ceedling.sh",
    ...
  ]
}

The eo build command

When you run eo build a few things happen:

  1. If you are running inside of a devcontainer, the pipeline.sh script is executed.
  2. If you are not running inside of a devcontainer, the pipeline.sh script is executed inside of the devcontainer.
  3. If no devcontainer is found, the pipeline.sh script is executed in the host environment.

Hosted / CI Pipeline Integration

Because pipeline providers have many different formats for defining pipelines, the pipeline.sh script and pipeline.json file are designed only to simulate a pipeline run locally.

Most EmbedOps templates will include step-specific ci/ scripts that will call the appropriate tool for that step. These steps are then referenced from the pipeline config file for your provider.

For example, in Gitlab CI, the root-level .gitlab-ci.yml file includes a glob expression pulling in all ci/**.gitlab.yml config files:

include:
  - 'ci/**.gitlab.yml'

So while this requires some dual maintenance, if you keep all build logic restricted to shell scripts within the ci/ directory, you can easily maintain a single source of truth for your build steps.