Configure workflows

Workflow guide

Configure parallel jobs, native GitHub cache, and workflow cancellation.

Keep workflow configuration in GitHub

Sprintbox provides the runner; your repository continues to define triggers, job dependencies, permissions, environment protection, secrets, and build steps. Change runs-on on each job you want Sprintbox to execute. A reusable workflow chooses its runner inside the called workflow.

Install the language version and tools your build needs using the appropriate setup steps. Avoid depending on a particular image's incidental packages without testing them. The smoke test in Quickstart prints the operating system and architecture to help check an environment.

Control parallel work

Each matrix entry is a separate job and needs runner capacity. Use GitHub's matrix max-parallel setting to bound the number of simultaneous entries:

jobs:
  test:
    strategy:
      max-parallel: 2
      matrix:
        shard: [1, 2, 3, 4]
    runs-on: sprintbox-standard-2
    timeout-minutes: 20
    steps:
      - run: echo "Run test shard ${{ matrix.shard }}"

Workspace concurrency limits and available capacity can cause additional waiting. A workflow's concurrency setting can prevent overlapping runs that should not execute together, such as deployments to the same environment.

Dependencies and cache

Sprintbox-managed caching is not available in this runner setup. GitHub's native cache can still be used through actions/cache or the cache options of supported setup actions. Manage those caches in GitHub; GitHub's cache access, retention, storage limits, and charges apply. See GitHub's dependency caching documentation.

Do not expect files from a previous job to remain on a runner. Use GitHub artifacts for files needed by later jobs, or your own external storage for persistent data. Dependency caches are an optimization and should not be required for a correct build.

Cancelling and retrying

Cancel a workflow from GitHub Actions. Sprintbox follows the job state and cleans up its runner. If a job failed because of a temporary setup or capacity issue, confirm it has ended before rerunning it in GitHub.