renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "description": "application-sdk dogfood config — extends its own fleet preset (renovate-config/default.json).",
  "extends": [
    "github>atlanhq/application-sdk//renovate-config/default.json"
  ],
  "semanticCommitType": "chore",
  "lockFileMaintenance": {
    "description": "Drop the fleet preset's postUpgradeTasks for THIS repo only. The preset's release-age bound (FND-359) runs as a post-upgrade command, which exists solely on the self-hosted runner — `allowedCommands` is admin-only, and this repo is excluded from the runner's discovery precisely so Mend can keep updating its action pins (the fleet App holds no `workflows: write`). Mend therefore sees a command it cannot run and publishes `renovate/artifacts: failure`, which the auto-approve gate reads as not-green and withholds on: measured, the lane went from `success` on #3216 to `failure` on the first branch Renovate rebased after #3227 merged, and that PR then sat unapproved. Clearing the commands here removes a signal that can only ever be false on this repo. The bound itself is NOT lost — `.github/workflows/renovate-lock-cooldown.yaml` applies the same driver to the branch Mend pushes (FND-376), which is the only place it can run here. Scoped to `commands` so the lane's schedule, automerge and labels all still come from the preset.",
    "postUpgradeTasks": {
      "commands": [],
      "fileFilters": [
        "uv.lock"
      ],
      "executionMode": "branch"
    }
  },
  "github-actions": {
    "description": "Also track SHA-pinned third-party actions in files outside the default github-actions fileMatch: the conformance bootstrap templates shipped in the package, and the .github/workflow-templates/ starter workflows (Renovate's default anchor for the latter is root-level workflow-templates/, so the nested copies are not matched by default). Scoped to those dirs so it never touches the .md doc examples or the actions_pinning test fixtures. Repo-local (not the fleet preset) because packages/conformance/ is SDK-specific.",
    "managerFilePatterns": [
      "/^packages/conformance/conformance/bootstrap/templates/.+\\.ya?ml$/",
      "/^\\.github/workflow-templates/.+\\.ya?ml$/"
    ]
  },
  "pre-commit": {
    "description": "Enable Renovate's pre-commit manager (FND-4247). It is off by default upstream, so every hook rev in .pre-commit-config.yaml only moved when someone bumped it by hand, and the hooks froze: ruff sat at v0.6.4 and isort at 5.13.2 while the dev group locked isort 9.0.2. The manager reads `rev:` against each hook repo's tags (datasource github-tags). Repo-local because only this repo's .pre-commit-config.yaml is in scope; the fleet's connector repos run their own hooks and are untouched. The packageRules below give it a release-age hold, keep ruff's three pins in one PR, and exclude the renovate validator hook, whose rev is tied to the runner's CLI pin.",
    "enabled": true
  },
  "customManagers": [
    {
      "description": "Pkl toolchain pin: track PKL_VERSION in application_sdk/pkl_version.py, the single place the version is declared (FND-1864). Repo-local rather than in the fleet preset because the file is SDK-only — connector repos consume the pin through the SDK package and the reusable workflows, and have nothing of their own to bump. github-tags rather than github-releases: apple/pkl tags each release as a bare version (`0.32.1`, no `v`), which `semver` versioning reads directly, and the tags datasource is the one the fleet's release-age handling is exercised against (see the app-contract-toolkit manager in the preset).",
      "customType": "regex",
      "managerFilePatterns": [
        "/^application_sdk/pkl_version\\.py$/"
      ],
      "matchStrings": [
        "PKL_VERSION\\s*:\\s*str\\s*=\\s*\"(?<currentValue>[^\"]+)\""
      ],
      "depNameTemplate": "pkl",
      "packageNameTemplate": "apple/pkl",
      "datasourceTemplate": "github-tags",
      "versioningTemplate": "semver"
    },
    {
      "description": "uv binary cache key in setup-deps (FND-4242). The github-actions manager bumps astral-sh/setup-uv's `version:` input (dep astral-sh/uv) but cannot see the same version inside the actions/cache key one step earlier, so the key drifted (0.11.21 against an installed 0.13.4) and the cache restored a uv nobody used. This manager tracks the key literal under the same depName; the packageRule below groups it into the github-actions PR so both land in one Renovate branch. If it ever stops matching, .github/scripts/tests/test_setup_deps_uv_cache_key.py fails on the bump PR instead of the drift going silent.",
      "customType": "regex",
      "managerFilePatterns": [
        "/^\\.github/actions/setup-deps/action\\.yaml$/"
      ],
      "matchStrings": [
        "key: uv-bin-\\$\\{\\{ runner\\.os \\}\\}-\\$\\{\\{ runner\\.arch \\}\\}-(?<currentValue>\\d+\\.\\d+\\.\\d+)"
      ],
      "depNameTemplate": "astral-sh/uv",
      "datasourceTemplate": "github-releases",
      "versioningTemplate": "semver"
    }
  ],
  "packageRules": [
    {
      "description": "Pkl toolchain bumps are reviewed, never auto-merged — deliberately unlike every other lane in the fleet preset. pkl is a language, not a pinned library: one line here changes the renderer that every contract in the fleet is evaluated with, and a release that alters generated output would drift 22 connector repos at once with no PR of their own to notice it on. The SDK's own CI does prove the bump is safe — application_sdk/pkl_version.py is in sdk-gate.yaml's `toolkit` filter, so contract-toolkit-reusable.yaml regenerates every examples/ tree with the new pkl and fails on any diff — but 'green' there means 'the toolkit examples are unchanged', which is evidence for a human to weigh against the real contracts, not a substitute for weighing it. The review does not replace a release-age hold: the next rule holds the bump for the fleet's 3-day cooldown before a PR is opened at all.",
      "matchManagers": [
        "custom.regex"
      ],
      "matchDepNames": [
        "pkl"
      ],
      "automerge": false,
      "platformAutomerge": false,
      "semanticCommitType": "chore",
      "commitMessageTopic": "the pinned pkl toolchain"
    },
    {
      "description": "Hold pkl bumps for the fleet's 3-day release-age cooldown (FND-4356), the same window as the preset's third-party PyPI rule and renovate-lock-cooldown.yaml's --window P3D. The 3 days is a recorded exception to the org baseline's 7 (docs/standards/ci.md, 'Renovate release-age windows', FND-4651). The preset's rule matches only the pypi datasource, so without this the pkl lane had no hold. That let Renovate open application-sdk#4539 in the hour between apple/pkl pushing the 0.32.2 tag and publishing the release that carries the binaries, and every install-pkl download in its CI returned 404. The github-tags datasource gives each tag a releaseTimestamp: the annotated tag's tagger date, raised to the GitHub release's publishedAt when the release is later. So the 3 days run from when the binaries exist whenever the release is visible to Renovate, and the tag-before-assets race is closed either way. apple/pkl's tags are annotated and carry tagger dates, which matters because Renovate's default minimumReleaseAgeBehaviour (timestamp-required) silently suppresses an update with no timestamp. Positive matchUpdateTypes, the same shape as the preset rule, so no timestamp-less update type is caught. A separate rule from the review rule above, so that rule's automerge: false still covers every pkl update type.",
      "matchManagers": [
        "custom.regex"
      ],
      "matchDepNames": [
        "pkl"
      ],
      "matchUpdateTypes": [
        "major",
        "minor",
        "patch"
      ],
      "minimumReleaseAge": "3 days"
    },
    {
      "description": "Action bumps inside the shipped conformance bootstrap templates are conformance-package source changes: the PR-title gate requires a fix(conformance) scope for anything under packages/conformance/ (except tests/ and lock files), and these bumps change the package's scaffolded output so they should version it. Give them their own group + semantic type/scope so the PR title is deterministic and never collides with plain .github/workflows or .github/workflow-templates action bumps (which stay chore(deps)). Repo-local packageRules are appended after the fleet preset, so this overrides both the preset's force-chore rule and its github-actions groupName — but only for deps whose file lives under the templates dir (matchFileNames).",
      "matchManagers": [
        "github-actions"
      ],
      "matchFileNames": [
        "packages/conformance/conformance/bootstrap/templates/**"
      ],
      "groupName": "conformance action templates",
      "semanticCommitType": "fix",
      "semanticCommitScope": "conformance"
    },
    {
      "description": "Hold the Python runtime (actions/setup-python python-version) below 3.15 for now. The github-actions manager extracts the `python-version` input as dep `python` (depType `uses-with`), and Renovate classifies 3.14 → 3.15 as a minor, which the fleet preset's github-actions rule would otherwise group and automerge alongside routine action bumps (see application-sdk PR 4329). An allowedVersions cap rather than a custom versioning regex: actions/python-versions tags carry a build suffix (e.g. `3.13.0-11228421917`), and a regex that misses that format would silently stop tracking Python. Matched by depName with no matchFileNames, so it applies to .github/workflows, .github/workflow-templates and the conformance bootstrap templates alike, and every other github-actions update keeps its group and automerge. Raise or remove this cap when we deliberately move to 3.15 (consider dependencyDashboardApproval at that point).",
      "matchManagers": [
        "github-actions"
      ],
      "matchDepNames": [
        "python"
      ],
      "allowedVersions": "<3.15"
    },
    {
      "description": "Put the uv cache-key bump in the same PR as the setup-uv `version:` bump it must track. The fleet preset's github-actions group rule matches on matchManagers github-actions only, so a shared depName is not enough: the regex manager's astral-sh/uv bump fell outside the group and a github-actions PR bumped the install without the key, failing test_setup_deps_uv_cache_key.py. Same groupName and auto-merge settings as the preset's rule, because Renovate auto-merges a group only when every member does.",
      "matchManagers": [
        "custom.regex"
      ],
      "matchDepNames": [
        "astral-sh/uv"
      ],
      "groupName": "github-actions",
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true
    },
    {
      "description": "The same 7-day release-age hold as the preset's github-actions rule (FND-4651), which covers astral-sh/setup-uv's `version:` input (dep astral-sh/uv, github-releases) but not this regex manager. Without it the two halves of one bump would age differently: the cache key would be proposed the day uv publishes, a week before the install it must match, and land alone in the github-actions PR, failing test_setup_deps_uv_cache_key.py. github-releases carries a published timestamp, so the default timestamp-required behaviour delays rather than suppresses. Positive matchUpdateTypes, the same shape as the preset's rules. Majors need no rule: the preset disables custom.regex majors outright.",
      "matchManagers": [
        "custom.regex"
      ],
      "matchDepNames": [
        "astral-sh/uv"
      ],
      "matchUpdateTypes": [
        "major",
        "minor",
        "patch"
      ],
      "minimumReleaseAge": "7 days"
    },
    {
      "description": "pyatlan floor lane (FND-4439): on every pyatlan release, raise the `pyatlan>=X` floor the SDK PUBLISHES (root pyproject.toml and packages/api's `pyatlan` extra) instead of only moving this repo's lock, so the next SDK release carries the new pyatlan to every app. Under the preset's default rangeStrategy an in-range release produces no PR at all and reaches only this repo's uv.lock through lockFileMaintenance, which apps never see. groupName splits pyatlan out of the preset's 'non-critical python dependencies' group so both manifests move in one PR on its own branch (renovate/pyatlan; a major lands on renovate/major-pyatlan via separateMajorMinor). packages/conformance does not declare pyatlan, so Renovate cannot touch its lock: .github/workflows/renovate-pyatlan-sync.yaml moves that lock to the root's pyatlan and regenerates relationship_directions.json on the minor/patch branch. No matchUpdateTypes: the rule applies to every update type, and the next rule takes majors back out of auto-merge (under rangeStrategy bump Renovate keeps updateType minor/patch and only adds `bump` as a second matchable type, so either shape would match; this one does not depend on that). semanticCommitType is restated so the commit type does not hinge on rule order against config:recommended's fix-for-deps preset. No minimumReleaseAge: pyatlan is Atlan-published and exempt from the cooldown (FND-378), and upstream exempts `bump` regardless. Mend cannot run postUpgradeTasks, which is why the regeneration is a workflow and not a task here.",
      "matchDatasources": [
        "pypi"
      ],
      "matchPackageNames": [
        "pyatlan"
      ],
      "groupName": "pyatlan",
      "rangeStrategy": "bump",
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true,
      "semanticCommitType": "chore"
    },
    {
      "description": "pyatlan majors are reviewed, never auto-merged: a major raises the SDK's `<N+1` cap, which is the control point for a pyatlan major reaching every connector (see the preset's FND-378 note), and the conformance lock cannot follow it until an SDK release does. Separate from the rule above so that rule can stay update-type-agnostic; the preset's major rule still gives it the lowest prPriority.",
      "matchDatasources": [
        "pypi"
      ],
      "matchPackageNames": [
        "pyatlan"
      ],
      "matchUpdateTypes": [
        "major"
      ],
      "automerge": false,
      "platformAutomerge": false
    },
    {
      "description": "Release-age hold for pre-commit hook bumps (FND-4247): the fleet's 3-day cooldown, the same window as the preset's third-party PyPI rule and the pkl rule above. The 3 days is a recorded exception to the org baseline's 7 (docs/standards/ci.md, 'Renovate release-age windows', FND-4651). The preset's cooldown matches only the pypi datasource, so without this a hook tag would be proposed the hour it is pushed. github-tags gives each tag a releaseTimestamp (tagger date, or commit date for a lightweight tag), so the default timestamp-required behaviour delays rather than suppresses. Positive matchUpdateTypes, the same shape as the preset rule, so no timestamp-less update type is caught. Not auto-merged: a hook bump changes what CI enforces, and a linter release can fail files that passed yesterday, so a human reads the PR.",
      "matchManagers": [
        "pre-commit"
      ],
      "matchUpdateTypes": [
        "major",
        "minor",
        "patch"
      ],
      "minimumReleaseAge": "3 days"
    },
    {
      "description": "One PR for every ruff pin (FND-4247): the ruff-pre-commit hook rev (pre-commit manager, depName astral-sh/ruff-pre-commit) and the `ruff==` dev pins in pyproject.toml and packages/conformance/pyproject.toml (pypi). They are separate datasources, so without a shared group Renovate would bump them in separate PRs, and local `uv run ruff` would lint and sort differently from CI until the others caught up. .github/scripts/tests/test_lint_guards.py fails any PR that moves one without the others. groupName also takes the pypi pins out of the preset's 'non-critical python dependencies' group. Never auto-merged, for the same reason as the hook rule above: ruff 0.17 widened its default rule set, and a minor can reformat files.",
      "matchPackageNames": [
        "ruff",
        "astral-sh/ruff-pre-commit"
      ],
      "groupName": "ruff",
      "automerge": false,
      "platformAutomerge": false
    },
    {
      "description": "Leave the renovatebot/pre-commit-hooks rev to a human (FND-4247). Its hook installs renovate@<rev>, which must equal the CLI pin in .github/workflows/renovate.yaml (test_renovate_validator_pin.py), and nothing tracks that npm pin. A bump of the hook alone would fail that parity test on every PR Renovate opens, so the two stay hand-bumped together, as before the pre-commit manager was enabled.",
      "matchManagers": [
        "pre-commit"
      ],
      "matchPackageNames": [
        "renovatebot/pre-commit-hooks"
      ],
      "enabled": false
    },
    {
      "description": "Leave the Dockerfile's golden base (cgr.dev/atlan.com/app-framework-golden) untracked. The registry is private and Renovate has no credentials for it, so every lookup fails and logs a warning (application-sdk PR 2049). The tag stays mutable on purpose: Chainguard rebuilds it as package fixes land, and an untracked digest pin would freeze those fixes out. The release build's SLSA provenance records the digest each app-runtime-base release shipped on. The policy is written down next to the FROM line in the Dockerfile and in docs/standards/build-security.md. Disabled by depName here rather than listed in ignoreDeps, so the reason sits with the rule.",
      "matchDepNames": [
        "cgr.dev/atlan.com/app-framework-golden"
      ],
      "enabled": false
    }
  ],
  "ignorePaths": [
    "contract-toolkit/examples/**"
  ]
}