CI/CD and Releases

This document describes the Continuous Integration, Continuous Deployment (CI/CD), and release processes for the EigenLayer-AVS project.

This document describes the Continuous Integration, Continuous Deployment (CI/CD), and release processes for the EigenLayer-AVS project. It covers the GitHub Actions workflows that automate testing, code formatting, Docker image building, and the creation of release artifacts.

For information about testing the system, see Testing. For information about configuration options, see Configuration.

Table of Contents#

CI/CD Overview#

The EigenLayer-AVS project employs a comprehensive CI/CD pipeline built on GitHub Actions to ensure code quality, automate testing, and streamline the release process. The pipeline automates several key processes:

  1. Code formatting on push
  2. Automated testing
  3. Development Docker image builds
  4. Release builds for multiple platforms
  5. Docker image publication

The following diagram illustrates the overall CI/CD flow:

Sources:

GitHub Actions Workflows#

The CI/CD pipeline consists of three main GitHub Actions workflows:

Push Workflow#

The Push workflow runs automatically when changes are pushed to Go files in the repository. It has two main jobs:

  1. Format and Commit: Automatically runs gofmt on the codebase and commits any formatting changes.
  2. Publish Dev Build: Builds and publishes a development Docker image to Docker Hub (repository: avaprotocol/avs-dev).

Sources:

Test Workflow#

The Test workflow runs all unit tests to ensure code reliability. It uses a matrix strategy to run tests for different components in parallel.

The test matrix includes the following components:

  • aggregator
  • core/taskengine
  • core/taskengine/trigger
  • core/taskengine/macros
  • pkg/timekeeper
  • pkg/graphql
  • pkg/byte4
  • pkg/erc4337/preset
  • core/backup
  • core/migrator
  • migrations

Sources:

Release Workflow#

The Release workflow is triggered when a tag starting with "v" is pushed to the repository (e.g., v1.0.0) or when manually triggered. It handles:

  1. Docker Image Publication: Builds and publishes the official Docker image to Docker Hub.
  2. Binary Builds: Compiles binaries for multiple platforms (macOS and Linux, both AMD64 and ARM64).
  3. GitHub Release Creation: Creates a GitHub release with the compiled binaries and release notes.

Sources:

Release Process#

The release process for EigenLayer-AVS follows these steps:

  1. Create a Release Tag: Create and push a tag starting with "v" (e.g., v1.2.3)

  2. Automated Release Build: The tag triggers the release workflow automatically

  3. Binary Generation: The workflow compiles binaries for multiple platforms

  4. Docker Image Building: A Docker image is built and tagged with the version

  5. Release Publication: A GitHub release is created with:

    • The compiled binaries
    • Release notes generated from Git history since the previous tag
    • The release is initially created as a draft

Release Tags#

The Docker images use the following tagging strategy:

  • Latest version: latest (only for main branch)
  • Commit SHA: <sha>
  • Branch name: <branch-name>
  • Semantic versioning: <version> and <major>.<minor>

Sources:

Docker Images#

EigenLayer-AVS provides two Docker repositories:

  1. Development Images (avaprotocol/avs-dev):

    • Built on each push to the repository
    • Tagged with the commit SHA, branch name, and PR number
    • Used for testing and development purposes

  2. Release Images (avaprotocol/ap-avs):

    • Built when a release tag is pushed
    • Contains the official release version
    • Tagged with semantic version numbers

The Docker images are built for multiple platforms:

  • linux/amd64
  • linux/arm64

The Docker build process uses the following Dockerfile: dockerfiles/operator.Dockerfile.

Sources:

Version Management#

The EigenLayer-AVS project embeds version information into the binary during the build process. The version information is handled by the version package and can be accessed via the version command:

During the build process, the version is injected via the -ldflags option in the Go build command:

-ldflags "-X github.com/AvaProtocol/ap-avs/version.semver=${{ inputs.tag || github.ref_name }}"

This sets the semver variable in the version package to the tag name (e.g., v1.2.3) or the branch name if building from a branch.

Sources:

Configuration for Deployment#

When deploying the EigenLayer-AVS system, configuration is loaded from YAML files. The configuration includes environment-specific settings like:

  • Ethereum RPC URLs
  • Contract addresses
  • Private keys
  • Database paths
  • JWT secrets
  • Smart wallet configurations
  • Backup settings

The CI/CD pipeline does not directly handle configuration files, as they are specific to each deployment environment. Instead, the Docker images are built without configuration, and the configuration files are mounted or injected when the containers are run.

Sources:

This document provides an overview of the CI/CD and release processes for the EigenLayer-AVS project. For more detailed information about specific aspects of the system, refer to the other wiki pages.

Feature this wiki to auto refresh weekly

Try DeepWiki on your private codebase with Devin