chore: add dependabot config for automated PRs

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.

[jvsena42]

Description

This PR:

1. Adds a dependabot.yml covering the three package ecosystems this repo actually has — the test-push-server npm tree, the workflow actions, and the Xcode-managed Package.resolved
2. Groups each ecosystem into a single monthly PR to keep the CI cost of automated updates bounded
3. Excludes the Synonym-owned FFI packages, which cannot be bumped unattended

The repo has had Dependabot alerts enabled for a long time but has never had a Dependabot pull request — there is no config file, so nothing was ever proposed. All 30 historical alerts are closed as fixed because they were cleaned up by hand, most recently in #651. This is the piece that stops that from being manual work.

One thing this does not do on its own, and it is the important caveat: a config file only turns on version updates. Turning an advisory into a pull request is a separate repo setting, and it needs admin on the repo. Merging this alone will not make alerts arrive as pull requests. The two halves are complementary: version updates keep dependencies current so advisories land less often, security updates handle the ones that land anyway.

Admin steps to finish enabling this

Either tick Settings → Advanced Security → Dependabot security updates, or run the equivalent from the CLI. Both endpoints require admin on the repository and return 204 No Content on success:

# Dependabot alerts — already on here, but idempotent and safe to re-run
gh api --method PUT repos/synonymdev/bitkit-ios/vulnerability-alerts
# Dependabot security updates — this is the one that turns an alert into a pull request
gh api --method PUT repos/synonymdev/bitkit-ios/automated-security-fixes

Verify afterwards:

# expect {"enabled": true, "paused": false}
gh api repos/synonymdev/bitkit-ios/automated-security-fixes
# expect HTTP/2.0 204 — a 404 means either disabled or the caller is not an admin
gh api repos/synonymdev/bitkit-ios/vulnerability-alerts --include | head -1

The dependency graph needs no action: it is on by default for public repositories and cannot be turned off.

Swift is included because it only recently became possible. Dependabot required a top-level Package.swift until 31 March 2026, when it gained the ability to discover Package.resolved nested inside .xcodeproj and .xcworkspace bundles and to read version rules out of project.pbxproj. That is exactly this repo's layout, so the ecosystem is supported here for the first time. It is also the least proven part of the change, which is why the QA notes below include a fallback to an explicit directories: path if the resolver does not find the manifest.

Grouping is the cost control rather than a tidiness preference. Unit tests and integration tests run on every pull request with no path filter, both on macos-15 with hour-long timeouts, and the e2e suite fires on anything touching Bitkit.xcodeproj/** or its own workflow file — which a Swift bump and an actions bump respectively do. Ungrouped, a month with six updates is six full CI runs. Grouping holds it to a handful.

Majors are kept out of the routine batches, but how that is expressed differs by ecosystem. For npm and swift the groups take minor and patch only, so a major bump falls through to its own pull request. Actions are a different case: every one of them is pinned to a floating major tag (actions/checkout@v6, upload-artifact@v7, and so on), so every update Dependabot can propose for them is a major one. Restricting that group the same way would mean it never fires and each action arrives as its own pull request with its own full CI run. Instead the actions entry has two groups, minor/patch and major, both matching everything — a dependency lands in the first group it matches, so major action bumps get a dedicated pull request separate from routine updates without fanning out into eight of them.

The four ignored packages are bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs. Two are on release candidates, one is pinned to a branch revision, and all four are bumped in lockstep with native code, so an unattended bump produces a red pull request rather than a useful one — #632 spent a cycle on exactly that failure mode. Ignoring them leaves lottie-ios, CodeScanner and swift-secp256k1 updating automatically, which is the subset where an automated bump is worth reviewing. The ignore rules use globs rather than exact names because the Swift ecosystem is inconsistent about whether a dependency is identified by its bare name or its full repository URL, and an exact match that misses fails silently.

No app code is touched, so there is no changelog fragment.

Linked Issues/Tasks

• Follows chore: remove vulnerable npm deps from dev tooling #651, which cleared the alerts this config is meant to keep from accumulating again
• Swift ecosystem support for .xcodeproj manifests: https://github.blog/changelog/2026-03-31-dependabot-now-supports-xcode-projects-using-swiftpm-with-xcodeproj-manifests/
• Sibling precedent: synonymdev/bitkit-android.github/dependabot.yml

Screenshot / Video

N/A — repository configuration only.

QA Notes

Manual Tests

Dependabot reads dependabot.yml from the default branch only, so none of these can run until this merges. Each row in the Dependabot tab has a Check for updates button that forces a run without waiting for the monthly schedule.

• 1. Insights → Dependency graph → Dependabot: three rows listed (npm, GitHub Actions, Swift), each with a Last checked timestamp and no config error banner.
• 2a. Dependabot tab → Swift row → Check for updates → open the job log: lottie-ios, CodeScanner and swift-secp256k1 are resolved from the Xcode-managed manifest.
  • 2b. Same log: bitkit-core, ldk-node, vss-rust-client-ffi and paykit-rs are skipped as ignored rather than proposed.
  • 2c. If the log reports no manifest found, replace directory: / on the swift entry with directories: ["/Bitkit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm"] and re-run.
• 3. Dependabot tab → npm row → Check for updates: resolves test-push-server/package-lock.json and does not look at the repo root.
• 4a. Dependabot tab → GitHub Actions row → Check for updates: proposes one grouped pull request rather than one per action.
  • 4b. That pull request is the github-actions-major group, since every action here is pinned to a floating major tag; github-actions-minor produces nothing.
• 5. Repo admin → run the two gh api --method PUT commands above (or tick Settings → Advanced Security) → gh api repos/synonymdev/bitkit-ios/automated-security-fixes: returns enabled: true, paused: false. Until this is done, advisories will not open pull requests.
• 6. First grouped pull request Dependabot opens → unit-tests and integration-tests: both green. Dependabot pull requests run with a read-only token and no repository secrets, so if the e2e suite fails for want of CHATWOOT_API that needs a Dependabot secret or an author guard, in a follow-up.

Automated Checks

• No Swift or app code changed, so no test coverage was added, modified or removed.
• npx -y js-yaml .github/dependabot.yml parses cleanly and yields all three updates entries with the intended ecosystems, directories, groups and ignore rules.
• Schema validity is enforced by GitHub rather than locally: an invalid dependabot.yml is annotated directly on the pull request, so the absence of a Dependabot annotation here is the check.
• Ecosystem resolution and grouping behaviour can only be observed once the config is on the default branch (after merge); that is what the manual steps above cover.
• CI: standard checks run by the PR bot.

[greptile-apps]

Greptile Summary

The PR adds monthly Dependabot version-update configuration for the repository’s npm, GitHub Actions, and Xcode-managed Swift dependencies.

• Groups routine dependency updates by ecosystem to limit CI usage.
• Excludes four native Swift dependencies that require coordinated manual upgrades.
• Configures ecosystem-specific commit prefixes and pull-request limits.

Confidence Score: 4/5

The GitHub Actions grouping configuration should be fixed before merging because it bundles major action upgrades that the PR intends to isolate for review.

The catch-all GitHub Actions group lacks the minor/patch filter present on the npm and Swift groups, so major action upgrades enter the grouped monthly pull request.

Files Needing Attention: .github/dependabot.yml

Important Files Changed

Filename	Overview
.github/dependabot.yml	Adds the three intended Dependabot ecosystems, but the GitHub Actions group unintentionally includes major updates despite the stated standalone-review policy.

_{Reviews (1): Last reviewed commit: "chore: add dependabot config" | Re-trigger Greptile}

[ovitrif]

The Dependabot config matches the repo: npm under test-push-server, Actions at root with major/minor groups for floating tags, and Swift ignores for the Synonym FFI packages that need coordinated bumps.