This directory contains GitHub Actions workflow configurations for the Open Badges Modular Server project.
The release workflow is triggered when code is pushed to the main branch. It uses semantic-release to automate the versioning and release process.
- Trigger: Push to
mainbranch - Permissions: Write access to contents, issues, and pull requests
- Steps:
- Checkout the repository with full history
- Set up Node.js and Bun
- Install dependencies
- Run tests
- Build the application
- Run semantic-release to create a new release
GITHUB_TOKEN: GitHub token for authentication (provided by GitHub Actions)GH_TOKEN: Same as GITHUB_TOKEN, but used by semantic-releaseNPM_TOKEN: A dummy token to satisfy semantic-release requirements (not used for actual publishing)
The semantic-release configuration is defined in .releaserc.json at the root of the repository. It uses the following plugins:
@semantic-release/commit-analyzer: Analyzes commit messages to determine the next version@semantic-release/release-notes-generator: Generates release notes based on commit messages@semantic-release/changelog: Updates the CHANGELOG.md file@semantic-release/npm: Updates the version in package.json (does not publish to NPM)@semantic-release/git: Commits the updated files back to the repository@semantic-release/github: Creates a GitHub release
- The
@semantic-release/npmplugin is configured withnpmPublish: falsesince we're not publishing to NPM. - We're using a dummy NPM token to satisfy semantic-release requirements.
- We set up Git identity explicitly to ensure proper commit attribution.
- We use debug mode for semantic-release to get more detailed logs.
- We've defined explicit release rules for different commit types.
The Docker build workflow is triggered when a new release is published by the release workflow. It builds and pushes a Docker image to the GitHub Container Registry (ghcr.io).
- Trigger: Release published event or manual workflow dispatch
- Permissions: Read access to contents, write access to packages
- Steps:
- Checkout the repository at the release tag
- Set up Docker Buildx
- Login to GitHub Container Registry
- Extract metadata for Docker image
- Build and push the Docker image
- Update the Docker image description
The Docker image is tagged with multiple versions to support different use cases:
- Full semantic version (e.g.,
v1.2.3) - Major.minor version (e.g.,
v1.2) - Major version only (e.g.,
v1) - Branch name (for non-release builds)
- Short commit SHA (for debugging)
The complete release process follows these steps:
- Code is pushed to the
mainbranch - The release workflow runs semantic-release to:
- Determine the next version number
- Update package.json and CHANGELOG.md
- Create a git tag
- Create a GitHub release
- The GitHub release triggers the Docker build workflow
- The Docker build workflow builds and pushes the Docker image to ghcr.io
- Release not created: Check if your commit messages follow the Conventional Commits format.
- Authentication errors: Ensure the workflow has the correct permissions set.
- NPM publishing errors: These should not occur since we've disabled NPM publishing.
- Docker build failures: Check the Dockerfile for errors or missing dependencies.
- Missing Docker image tags: Ensure the release was properly created and tagged.
To debug the release process locally, you can run:
bun run release:dry-runThis will show what would happen during a release without making any changes.
To manually trigger a Docker build for a specific tag:
- Go to the Actions tab in GitHub
- Select the "Build and Push Docker Image" workflow
- Click "Run workflow"
- Enter the tag to build (e.g.,
v1.0.0) or leave empty for the latest release