{
    "version": "1.5.0",
    "item": {
        "id": "blog_v105",
        "title": "Speeding Up CI on GitHub Actions: Shards and Merge Queues | DBETA",
        "url": "https://www.dbeta.co.uk/blog/speeding-up-ci-github-actions-shards-merge-queue.html",
        "summary": "Ways to speed up continuous integration (CI) on GitHub Actions, as DBETA applies them to its own platform: run only fast checks for documentation-only changes; split long test stages into parallel shards built from one shard map, each with its own timeout and the same quality floor; defer the heaviest tests from pull requests to the merge queue; and cancel a merge-queue run as soon as a required job fails. Skipped or deferred checks are reported as such, never as passes.",
        "category": "Software Engineering",
        "image": "https://dbeta.b-cdn.net/covers/ai-ready-web-design-agency.jpg",
        "author": {
            "name": "Donatas Tranauskis",
            "url": "https://www.donatastranauskis.com"
        },
        "published_at": "2026-11-02T00:00:00+00:00",
        "updated_at": "2026-11-02T00:00:00+00:00",
        "faqs": [
            {
                "question": "What is CI sharding?",
                "answer": "Splitting one long test stage into several smaller jobs that run at the same time, each covering part of the code. On GitHub Actions this is usually done with a job matrix."
            },
            {
                "question": "Does a merge queue slow developers down?",
                "answer": "It moves the heaviest checks from every pull request push to one run just before merging. Pull requests get quicker feedback, and main is still only updated after the full checks pass."
            },
            {
                "question": "Is it safe to skip tests for documentation-only changes?",
                "answer": "Only if the rule is strict: every changed file must be documentation, anything mixed or unrecognised runs everything, and the check reports \"skipped\" rather than \"passed\"."
            },
            {
                "question": "How do you cancel a CI run that is going to fail?",
                "answer": "Turn on fail-fast for matrix jobs where the result must be all-or-nothing, and add a step that cancels the whole run when a long required job fails. Make sure the final gate still runs and reports the failure."
            }
        ],
        "sources": [
            {
                "label": "GitHub Docs - Running variations of jobs in a workflow (matrix)",
                "url": "https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations"
            },
            {
                "label": "GitHub Docs - Managing a merge queue",
                "url": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue"
            },
            {
                "label": "GitHub Docs - Control the concurrency of workflows and jobs",
                "url": "https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency"
            },
            {
                "label": "GitHub Docs - Actions limits",
                "url": "https://docs.github.com/en/actions/reference/limits"
            }
        ]
    }
}