This page provides a high-level overview of the automated testing and release infrastructure for the skill-up project. The codebase utilizes GitHub Actions for continuous integration, a multi-stage testing strategy (unit and E2E), and GoReleaser for automated distribution.
The project defines several GitHub Actions workflows to maintain code quality and automate the release lifecycle. These workflows are located in .github/workflows/.
| Workflow | Purpose | Trigger |
|---|---|---|
CI (ci.yml) | Core pipeline: dependency verification, unit tests, linting, and quick E2E smoke tests `.github/workflows/ci.yml27-137 | PRs and Pushes to main |
Extended CI (extended-ci.yml) | Expensive/Long-running tests: Windows E2E, Docker integration, and GoReleaser dry-runs `.github/workflows/extended-ci.yml1-145 | Merge groups and manual dispatch |
Model E2E (model-e2e.yml) | Live-model tests consuming external API quota for none, opensandbox, and docker runtimes `.github/workflows/model-e2e.yml1-255 | Manual dispatch |
Docs (docs.yml) | Builds the VitePress site and deploys it to GitHub Pages `.github/workflows/docs.yml31-82 | Pushes affecting docs/ |
Release (release.yml) | Invokes GoReleaser to build binaries, attest artifacts, and create GitHub Releases `.github/workflows/release.yml17-145 | Tag creation (v*) |
CodeQL (codeql.yml) | Static analysis for security vulnerabilities across Go, Python, and Actions `.github/workflows/codeql.yml26-112 | Weekly schedule and Pushes to main |
The CI pipeline is split to optimize developer feedback. ci.yml provides a fast "Build & Test" job `.github/workflows/ci.yml28-56 and an e2e-smoke job that runs a subset of CLI and Runtime tests using the e2e build tag `.github/workflows/ci.yml67-86
For a deep dive into workflow definitions and build targets, see CI/CD Workflows.
Sources:
The testing architecture is split into two primary layers:
internal/. These use standard Go testing patterns and the race detector (-race) `.github/workflows/ci.yml54-55 They focus on isolated logic like configuration loading and credential resolution.e2e/. These tests exercise the full CLI pipeline, from command invocation to report generation. They are gated by the //go:build e2e constraint.The E2E framework is designed to validate the system across different runtimes and engines:
SKILL_UP_CONFIG_DIR environment variable to prevent interference between parallel test runs.SKILL_UP_E2E_ARTIFACT_DIR is set, the framework copies test workspaces to a target directory for post-mortem analysis `.github/workflows/ci.yml87-88none runtime (Host) `.github/workflows/extended-ci.yml16-50 docker runtime `.github/workflows/extended-ci.yml51-80 and opensandbox runtime `.github/workflows/model-e2e.yml141-255For detailed implementation details and fixture usage, see End-to-End Test Framework.
Sources:
Static analysis is enforced via golangci-lint and revive `.github/workflows/ci.yml127-136 The CI also verifies Go formatting using gofmt -l `.github/workflows/ci.yml117-126
The CI environment specifically includes a e2e-windows job to validate platform-specific logic, such as shell selection and MSYS argument handling, using a GitHub-hosted Windows runner `.github/workflows/extended-ci.yml16-20
Releases are managed by GoReleaser, which produces cross-platform binaries `.github/workflows/release.yml51-58 The process includes artifact attestation for provenance `.github/workflows/release.yml108-115
The following diagram illustrates how high-level CI/CD concepts map to specific entities in the codebase.
CI/CD Entity Mapping
Sources:
This diagram shows the relationship between the build tools, the testing framework, and the final artifacts.
Testing and Delivery Pipeline
Sources:
Child Pages: