CI/CD Pipeline

This document describes the Continuous Integration and Continuous Deployment (CI/CD) pipeline used in the Ava SDK JS repository.

This document describes the Continuous Integration and Continuous Deployment (CI/CD) pipeline used in the Ava SDK JS repository. It covers the automated processes for testing, version management, and release creation to ensure code quality and streamline development workflows.

For information about the release management process, see Release Management.

Overview#

The AVA SDK JS repository uses GitHub Actions to implement its CI/CD pipeline. The pipeline consists of several workflows that handle testing in different environments, version management with Changesets, and automated releases.

Sources:

Pull Request Testing Workflow#

When a pull request is created, it triggers automated tests in development and staging environments based on the target branch. The testing workflows check for changes in source code or test files and run a series of tests to verify functionality.

Sources:

Development Environment Tests#

The development environment testing workflow runs whenever a pull request is created. It uses a local Docker container to run the AVS aggregator service for testing.

Key characteristics:

  • Triggered by any pull request
  • Uses a local Docker environment
  • Runs only if source code or test files have changed
  • Tests against localhost:2206 endpoint

Test workflow steps:

  1. Check for changes in source code directories

  2. Start local AVS aggregator in Docker

  3. Install dependencies and build the project

  4. Create a test API key

  5. Run tests for various SDK functionalities:

    • Authentication
    • Workflow creation, retrieval, cancellation, and deletion
    • Execution retrieval
    • Wallet management
    • Secret management

Sources:

Staging Environment Tests#

The staging environment testing workflow runs when a pull request targets the main branch. It uses a remote staging environment for testing.

Key characteristics:

  • Triggered only by pull requests to main
  • Uses a remote staging environment specified in GitHub secrets
  • Runs only if source code or test files have changed
  • Tests against the remote endpoint defined in ENDPOINT environment variable

The staging test workflow follows the same test execution pattern as the development workflow but uses predefined API keys and endpoints for the staging environment.

Sources:

Changeset Management#

The repository uses Changesets to manage versioning and changelog generation. Changesets provide a way to document changes and automate version bumping.

The changeset workflow allows developers to:

  1. Record changes with appropriate version bumps (patch, minor, major)
  2. Automatically create a pull request with the changeset
  3. Generate changelogs for releases

Sources:

Recording a Changeset#

The record-changeset.yml workflow automates the process of creating a changeset. It can be manually triggered through the GitHub Actions interface with the following steps:

  1. Developer selects the version type (patch, minor, major)
  2. The workflow creates a new changeset file in the .changeset directory
  3. The changeset includes the package name and version bump type
  4. A new branch is created with the changeset
  5. A pull request is created targeting either main or staging branch

Sources:

Release Process#

The release process is automated through the create-release.yml workflow. This workflow is triggered manually on the main branch and handles version bumping and release creation.

Key steps in the release process:

  1. Checkout the repository with full history
  2. Install dependencies
  3. Run npx changeset version to process pending changesets
  4. Commit version bumps if any changes are detected
  5. Push changes to the main branch
  6. Check if the version in package.json has increased
  7. Create a GitHub release with auto-generated release notes

The release workflow only creates a new release if a version increment is detected between the current version and the latest release.

Sources:

Testing Infrastructure#

The CI/CD pipeline includes comprehensive testing of all SDK functionality. Tests are executed against both development and staging environments.

The testing process verifies all core functionality of the SDK:

Test CategoryFunctions TestedPurpose
AuthenticationauthWithAPIKey, authWithSignatureVerify authentication methods
Workflow ManagementcreateWorkflow, getWorkflow, getWorkflows, cancelWorkflow, deleteWorkflowTest workflow lifecycle management
ExecutiongetExecutionsVerify execution retrieval
Wallet ManagementgetWallet, getWalletsTest wallet retrieval functions
Secret ManagementSecret creation, listing, updating, deletionVerify secret management capabilities

Sources:

Environment Configuration#

The CI/CD pipeline uses different environment configurations for development and staging tests. These configurations are managed through GitHub secrets and environment variables.

Key environment variables:

  • TEST_API_KEY: API key for authentication
  • TEST_PRIVATE_KEY: Private key for signature-based authentication
  • ENDPOINT: Service endpoint (localhost for dev, remote for staging)
  • CHAIN_ENDPOINT: Blockchain endpoint for tests
  • RUN_ID: Unique identifier for the test run (staging only)

Sources:

Conclusion#

The CI/CD pipeline for Ava SDK JS provides a robust system for testing, versioning, and releasing code. It ensures that all changes are properly tested in both development and staging environments before being released. The use of Changesets simplifies version management and changelog generation, making the release process more reliable and transparent.