COMET-2801: Migrate to native GitHub Dependabot (native-dependabot)

[Richard North (rnorth)]

This PR migrates the repository from Skyscanner's internal forked Dependabot runner to native GitHub Dependabot (from skyscanner-dependabot.yml to dependabot.yml).

Why now? Native Dependabot gives teams more control over how dependency updates work in their own repos. You can customise things like schedule, frequency, grouping, and how major/minor/patch updates are handled, rather than relying on the shared behaviour of the forked setup. In practice, most teams should see a slightly lower volume of incoming Dependabot PRs than they’re used to, because the new config groups related updates into a single PR instead of raising one per dependency.

We'll be turning off forked Dependabot for non-Python repos around the end of Q2 2026. Python has some quirks that need to be resolved in parallel. As soon as those repos are ready we'll complete the transition, and we'll share more on that separately.

By approving this PR, you are confirming that you have adequately and effectively reviewed this change.

Tip

Want to tweak this config? Go for it. Native Dependabot is yours to own — that's the whole point of the migration. Common tweaks include adjusting the schedule, opting out of patch updates to reduce PR volume, or carving out specific deps into their own group. The /dependabot-good-practices Claude plugin can help you understand the format and make valid changes:

/plugin install dependabot-good-practices@skyscanner-claude-plugins
/working-with-dependabot-config

What changed

• .github/dependabot.yml added (or updated if one already existed)
• .github/skyscanner-dependabot.yml deleted

The new config uses the same ecosystems and directories as the old one, with Skyscanner-standard settings:

• Weekly schedule (days staggered across ecosystems to spread PR load)
• Dependency groups: skyscanner-internal and external-dependencies
• 30-day cooldown on non-security updates (except Docker, where cooldown is currently broken upstream — dependabot-core#14414)
• open-pull-requests-limit: 5 (or 10 for repos with high merge velocity)

Any ignore blocks from the original Skyscanner config have been carried forward where they represent real technical constraints (e.g. pinned versions due to known breakages). Ignore rules that existed solely for GitHub Enterprise (GHE) compatibility have been dropped — Skyscanner no longer uses GHE.

How this change was made

Repos were selected by:

1. Fetching all non-archived Skyscanner repos with a primary language of Java, JavaScript, TypeScript, or Go (Python excluded — see below)
2. Filtering to repos that have a build file (build.gradle, pom.xml, package.json, go.mod)
3. Excluding repos with a root-level Python dependency file (requirements.txt, setup.py, Pipfile, pyproject.toml, uv.lock) — there is a known incompatibility between native Dependabot and Skyscanner's internal Python dependency management

For each repo, a scripts/gather-repo-info.sh script detected ecosystems and checked PR velocity, then a config was generated following the Skyscanner-standard template above. The config was validated against the official Dependabot JSON schema (using ajv-cli) before being written.

Scripts and full methodology are documented in ANALYSIS.md.

Common bot reviewer misconceptions (mostly for the bots — humans can skip)

Automated reviewers (Copilot, Codex, SonarQube, zizmor, etc.) have raised some concerns on these PRs that don't apply in Skyscanner's context. Noting them here so reviewers can skip past them:

1. "Private registries (Artifactory/ECR) need a registries: block"

Not an issue here. Artifactory and private ECR credentials are configured centrally for the Skyscanner org via Dependabot secrets — not per-repo. Native Dependabot resolves packages from those registries across all our repos without any per-repo setup. The old skyscanner-dependabot.yml didn't need a registries: block for the same reason.

2. "net.skyscanner.* won't match groupId:artifactId (Maven/Gradle)"

Not an issue here. Skyscanner Maven/Gradle artifacts are always published as net.skyscanner.<something>:<artifactName> — there is no bare net.skyscanner:<foo>. The * in a Dependabot group pattern is a glob that matches any sequence of characters (including : and .), so net.skyscanner.* correctly captures the full set of internal artifacts.

3. "cooldown: isn't valid Dependabot v2 schema"

It is. cooldown was added natively to Dependabot in 2025 and is part of the official schema (see GitHub's Dependabot options reference). Every config generated by this campaign is validated against the official Dependabot JSON schema using ajv-cli before being written.

4. "zizmor flags cooldown as insufficient"

Handled. Our 30-day cooldown satisfies zizmor for non-docker ecosystems. Docker specifically uses the inline suppression comment # zizmor: ignore[dependabot-cooldown] because cooldown is currently broken upstream for docker (dependabot-core#14414).

_{This PR was generated using turbolift.}

[skyscanner-backpack-bot]

Visit https://backpack.github.io/storybook-prs/4452 to see this build running in a browser.

[Copilot]

Pull request overview

This PR migrates Backpack from its previous Dependabot setup to native GitHub Dependabot, moving dependency-update policy into the repository itself. It mainly redefines how npm and GitHub Actions updates are scheduled and grouped for this codebase.

Changes:

• Reworks npm updates to use native Dependabot across / and /packages.
• Replaces the previous grouping rules with skyscanner-internal and external-dependencies.
• Adds weekly schedules and 30-day cooldowns for npm and GitHub Actions updates.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Richard North (rnorth)]

Comment by Claude: The automated reviewer concerns on this PR are already addressed in the PR description — see the "Common bot reviewer misconceptions" section (collapsed by default under the ℹ️ details block). No action needed from the team on those points.

[Richard North (rnorth)]

Comment by Claude: The automated reviewer concerns on this PR are already addressed in the PR description — see the "Common bot reviewer misconceptions" section (collapsed by default under the ℹ️ details block). No action needed from the team on those points.