From 5c9381788bd74e8bf1e56f112dc029f9e580963f Mon Sep 17 00:00:00 2001 From: sirosen <1300022+sirosen@users.noreply.github.com> Date: Sun, 1 Nov 2026 11:11:07 +0000 Subject: [PATCH] [vendor-schemas] automated update --- CHANGELOG.rst | 2 + .../builtin_schemas/vendor/mergify.json | 139 ++++- .../builtin_schemas/vendor/renovate.json | 487 +++++++++++++++++- .../vendor/sha256/mergify.sha256 | 2 +- .../vendor/sha256/renovate.sha256 | 2 +- 5 files changed, 614 insertions(+), 18 deletions(-) diff --git a/CHANGELOG.rst b/CHANGELOG.rst index ca16b2403..1bc284529 100644 --- a/CHANGELOG.rst +++ b/CHANGELOG.rst @@ -10,6 +10,8 @@ Unreleased .. vendor-insert-here +- Update vendored schemas: mergify, renovate (2026-11-01) + 0.39.0 ------ diff --git a/src/check_jsonschema/builtin_schemas/vendor/mergify.json b/src/check_jsonschema/builtin_schemas/vendor/mergify.json index e2762b634..3febbf7fb 100644 --- a/src/check_jsonschema/builtin_schemas/vendor/mergify.json +++ b/src/check_jsonschema/builtin_schemas/vendor/mergify.json @@ -1063,7 +1063,7 @@ "type": "array" }, "strategy": { - "description": "How to merge a matching file when two pull requests of the same batch both change it. `union`, `ours` and `theirs` are git's names, and `ours` is always what the batch already holds, the base branch plus the pull requests queued ahead, and never the incoming pull request:\n\n- `union`: Keep both sides' lines where they conflict, the batch's first.\n- `ours`: Keep the batch's whole file and discard the incoming pull request's change to it, even where the two did not conflict.\n- `theirs`: Take the incoming pull request's whole file and discard the batch's, even where the two did not conflict.\n- `prefer-ours`: Merge normally, and keep the batch's side only on the lines that conflict -- its whole file when both sides added the file.\n- `prefer-theirs`: Merge normally, and keep the incoming pull request's side only on the lines that conflict -- its whole file when both sides added the file.\n- `json`: Merge a JSON file by its structure rather than by line, so changes to different keys or array elements merge even on adjacent lines, and neither side's change is discarded. Two different values for the same key, a change to a key the other side deleted, a key both sides added differently, two insertions at the same place in an array, or two changes to the same array element, even to different fields of it, are a conflict even where git's line merge would have been clean. Where git's line merge is clean and gives the same result, that text is used as is; otherwise the incoming pull request's changes are written into the batch's text as it wrote them, the rest keeps the batch's formatting and key order, and a change written in a style the batch's file does not use is a conflict. A file that is not valid JSON is merged by line as usual.\n- `pnpm`: Merge a `pnpm-lock.yaml` (lockfile version 9) entry by entry, so two pull requests updating two different dependencies merge even where their entries sit side by side, including when both moved peers of the same package. The same dependency updated to two versions, a package updated on one side while the other moved its peers, a dependency one side removed and the other updated, or a merged file whose entries refer to a package version it no longer has, are a conflict, even where git's line merge would have been clean. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A file that is not a version 9 lockfile is merged by line as usual.\n- `uv`: Merge a `uv.lock` and the `pyproject.toml` beside it entry by entry, so two pull requests updating two different dependencies merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same dependency updated to two versions; a dependency one pull request moved to another table while the other changed or removed it; a `uv.lock` package one side updated and the other changed, or one side changed while depending on a package the other side updated, since the lockfile records no version constraint to check the two against; and a merged `uv.lock` naming a package it no longer has, or holding one nothing uses. A file written in a shape uv does not write, such as a multi-line string, is merged by line as usual.\n- `rails-schema`: Merge a Rails `db/schema.rb` by line. When two pull requests that each add a migration both change its version line (`ActiveRecord::Schema[8.1].define(version: ...)`), keep the later version: what `rails db:migrate` writes once both migrations are applied. Any other conflict in the file, version lines written by two different Rails versions, or a version older than the one the file had before either change, is a conflict as usual.\n- `yarn`: Merge a `yarn.lock`, from yarn 1 or from yarn 2 and later, entry by entry, so two pull requests updating two different dependencies merge even where their entries sit side by side. The same dependency updated to two versions, a dependency one side removed and the other updated, the two sides holding different `__metadata`, or a merged file referring to a package version it no longer has, or holding one nothing uses, are a conflict, even where git's line merge would have been clean. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A file in neither yarn format is merged by line as usual.\n- `typescript`: Merge a TypeScript file (`.ts`, `.tsx`, `.mts`, `.cts`, `.d.ts`) or a JavaScript file (`.js`, `.jsx`, `.mjs`, `.cjs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, members, object keys, tests, cases of a test's `it.each([...])` table or JSX elements at the same place keep both: the batch's first, or in the order the file keeps them sorted in. The same declaration, statement or value changed two ways, a change to something the other side deleted, something one side moved and the other deleted or moved elsewhere, the same name added twice, statements added at the same place (in a function body, or a file's own, such as an `exports.name = ...` or a `require` call), declarations added at the same place that run code where they stand (a variable, a field or an object key whose value calls code, a decorated class), tests of a serial suite, table cases that run code or that the test's title numbers by their place (`%#`) or names alike, two enum members given the same value, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it declares a name twice in one scope with `let`, `const`, `class` or two imports -- the same constant added by both pull requests, one at each end of the file -- which is a conflict too, and a file that does not parse, is larger than 2 MiB, or is minified JavaScript (more than 110 characters a line on average) is merged by line as usual.\n- `rails-structure`: Merge the `schema_migrations` list Rails writes at the end of a `db/structure.sql`, so two pull requests that each add a migration merge even though both add a row at the same end of the list: it is written back with the migrations either side added and without those either side removed, sorted as Rails sorts it. The rest of the file is merged by line as usual, so the same table changed by both pull requests is still a conflict, and so are both sides re-sorting the list in opposite orders and a list left with no migration. A file without exactly one such list, as any other SQL file, is merged by line as usual.\n- `rust`: Merge a Rust file (`.rs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, items, methods, fields, enum variants, match arms or derives at the same place keep both: the batch's first, with imports and modules in rustfmt's order and layout. The same item or expression changed two ways, a change to something the other side deleted, the same name added twice, a macro both sides changed, items added at the same place whose order matters (a `macro_rules!`, a field of a `#[repr]` struct, a match arm with a guard), a match that would miss an enum variant the other side added, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it defines a name twice in one module, `impl`, struct or enum, or in two inherent `impl`s of one module written alike -- the same function added by both pull requests, one at each end of the file, not under two different `#[cfg]`s -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `python`: Merge a Python file (`.py`, `.pyi`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, tests, methods, string dictionary keys, keyword arguments or, in a `test_*.py` or `*_test.py` file, cases of a test's `@pytest.mark.parametrize` table (literals, with the ids it lists) at the same place keep both: the batch's first, and imports in the order isort and ruff write them, or the order the file already keeps where it plainly follows no sorter. Each keeps its own decorators, docstring, comments and indentation. A function both pull requests changed (but for a test each changed only cases of its table in, and different ones), table cases pytest names by their place (a dictionary, or a tuple that is the value of one argument, given no id) or would name alike, a case both changed, statements or class fields added at the same place, definitions or values whose decorators (other than a test's own marks, fixtures and patches, or, in a `test_*.py` or `*_test.py` file, the project's own that run nothing but values), defaults, annotations, operators or subscripts can run code, classes with a base that could register them, imports added to a section the file keeps sorted in an order other than isort's and ruff's own, a change to something the other side deleted, the same name added twice, a name one side removed that the other still uses, a block one side re-indented, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `yaml`: Merge a YAML file (`.yml`, `.yaml`) by its structure where git's line merge conflicts, so two pull requests adding different keys to a mapping keep both, the batch's first or in the order the mapping keeps its keys sorted in, and two adding items at the end of a sequence (a job's steps, a list of hosts) keep both, the batch's first, as do two changing different items of one (the action pinned on each of two neighbouring steps). An item holding a `name` (a step, a task, a container) is known by it, so two changing different entries of the same one keep both, unless one of them swapped entries the other kept for new ones (a task's module for a `block`). Each side's text is kept as it wrote it, comments included. The same key or item changed two ways, a change to something the other side deleted, the same key or name added twice, items added at the same place anywhere but the end of a sequence, an item both append among different ones, a document added, removed or replaced, an anchor one side changed while the other changed what refers to it, or a result that does not read back as both sides' changes are a conflict as usual. A merge git completes is left as git wrote it, unless it holds a key twice in one mapping -- the same key added by both pull requests, one at each end -- which is a conflict too, and a file that does not parse, is larger than 2 MiB, has more than 32,767 lines (16,383 with Windows line endings) or a longer line, or uses a list or an alias as a key is merged by line as usual. In Mergify's own configuration file, two rules or entries added at the same place, its end included, are a conflict in `pull_request_rules`, `queue_rules`, `priority_rules` and `conflict_resolvers`, whose order Mergify reads; two merge protections or two conditions added at the same place keep both; and two changing different entries of a rule keep both even where one swapped an entry for another.\n- `cargo`: Merge a `Cargo.lock` (lockfile version 3 or 4) and the `Cargo.toml` beside it entry by entry, so two pull requests updating or adding two different crates merge in both files even on adjacent lines, and two adding a crate to a workspace's `members` keep both. A conflict, even where git's line merge would have been clean: the same crate updated to two versions or changed two ways, or moved to another table by one pull request and changed or removed by the other; a `Cargo.lock` package one side changed while depending on a crate the other side removed or moved to a lower version, since the lockfile records no version constraint to check the two against; the two sides holding different lockfile versions; and a merged `Cargo.lock` that is not what Cargo writes, naming a package it no longer has, holding one nothing uses, or two versions of a crate Cargo would resolve to one. A file written in a shape Cargo does not write, such as a multi-line string, or an older lockfile version, is merged by line as usual.\n- `npm`: Merge a `package-lock.json` or an `npm-shrinkwrap.json` (lockfile version 2 or 3) entry by entry, so two pull requests updating or adding two different dependencies merge even where their entries sit side by side. A conflict, even where git's line merge would have been clean: the same package changed two ways; a package one side changed and the other removed; the two sides holding different lockfile versions; and a merged file in which a dependency would resolve to a version outside its range that no side resolved it to, or in which npm would mark a package development-only, optional or unused otherwise than the side it comes from does. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A version 1 lockfile, or a file laid out otherwise than npm writes it, is merged by line as usual.\n- `go`: Merge a Go file (`.go`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, methods, types, struct fields, interface methods, constants, map keys or rows at the end of a test table at the same place keep both: the batch's first, with imports in gofmt's order and the lines laid out as gofmt aligns them. The same declaration or value changed two ways, a function or a test table row both pull requests changed, a change to something the other side deleted, the same name declared twice, two constants given the same value, declarations added at the same place whose order matters (an `init` function, an `iota` constant, a variable or key whose value calls code, a field of a struct with a padding field), table rows added at the same place anywhere but the end, an import left unused or a package left without its import, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it declares a name twice in one place -- the same type added by both pull requests, one at each end of the file -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `gomod`: Merge a `go.mod` and the `go.sum` beside it entry by entry, so two pull requests updating or adding two different modules merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same module updated to two versions or changed two ways, in either file. Neither file records why a module is required, so a module one pull request removed is removed even where the other pull request's change needs it, including on lines git's line merge would have conflicted on, and Go then refuses to build until `go mod tidy` puts it back. A `go.mod` with a quoted string or a directive Go does not know is merged by line as usual.\n- `sbt`: Merge an sbt build file (`build.sbt`, `project/*.sbt`, `project/*.scala`, `project/build.properties`) by line as git does, except that a change rewriting only versions never conflicts with the lines around it: two pull requests bumping dependencies on adjacent lines, or one bumping a dependency beside a line the other adds or removes, merge, each version taken from the pull request that changed it. A version is a double-quoted string that reads as one, or the value of `project/build.properties`' `sbt.version`. The same version changed two ways, and lines both pull requests changed otherwise, such as two dependencies added at one place or one appended to a `Seq(...)` whose last element the other bumped, are a conflict as usual. A merge git completes is left as git wrote it.\n- `terraform`: Merge a `.terraform.lock.hcl`, from Terraform or OpenTofu, provider by provider, so two pull requests updating or adding two different providers merge even on adjacent lines, and so do two pull requests locking one provider version for two platforms. A conflict, even where git's line merge would have been clean: the same provider changed by both to two versions or under two sets of constraints. The lock file does not record why a provider is required, so a provider one pull request removed is removed even where the other pull request's change needs it, including on lines git's line merge would have conflicted on, and `terraform init` then puts it back. A lock file either pull request wrote in a layout Terraform does not write, such as with a `module` block or a list on one line, is merged by line as usual.\n- `nix`: Merge a `flake.lock` (lockfile version 7) input by input, so two pull requests updating or adding two different inputs merge, even where an input one adds makes Nix rename the nodes the other updated. A conflict, even where git's line merge would have been clean: the same input locked two ways, or locked by one side and removed by the other; a merged `flake.lock` with a `follows` leading to no input or a node nothing uses; and a merge base not written as Nix writes one under two sides that are. Either side not written as Nix writes one, or in an older lockfile version, is merged by line as usual. The `flake.nix` beside it is not read.\n- `ruby`: Merge a Ruby file (`.rb`, `.rake`, `.gemspec`, `.ru`, `.rbi`, a `Gemfile` or a `Rakefile`) by its syntax tree where git's line merge conflicts, so two pull requests adding different methods, attributes, constants, classes, requires, tests, `let` helpers, gem specification dependencies or hash keys at the same place keep both: the batch's first, with requires kept in the order the file sorts them. The same definition or value changed two ways, a method or a block of code both pull requests changed, a change to something the other side deleted, the same name defined twice, constants written together changed differently (a version's `TINY` on one side and `PRE` on the other), statements and class-body calls added at the same place whose order matters (`include`, `has_many`, `validates`, a hook, a Gemfile's `gem`), a method one pull request deleted that the other one's change still calls, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `swift`: Merge a Swift file (`.swift`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, types, extensions, methods of different names, protocol requirements, enum cases or properties at the same place keep both: the batch's first, with imports kept sorted where the file sorts them. The same declaration changed two ways, a function both pull requests changed, a change to something the other side deleted, the same name declared twice or two overloads of one name (two initializers among them), declarations added at the same place whose order matters (a statement, a stored property or a global variable whose value runs code, the case of an enum numbered or listed by its order), two cases given the same raw value, a case one pull request added beside a `switch` over its enum with no `default` the other wrote, a `#if` left without its `#endif`, an import one pull request removed while the other changed the file, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it redeclares something in one file or type -- the same method, with the same signature, added by both pull requests, one at each end of a type or one in each of two of its extensions that add no conformance, not under two different `#if`s -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `mix`: Merge a `mix.lock` dependency by dependency, and the `deps` list of the `mix.exs` beside it element by element, so two pull requests updating or adding two different packages merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same package changed two ways; a package one side changed and the other removed; and a merged `mix.lock` in which a Hex package's dependency is no longer locked at a version its recorded requirement accepts, unless a side holds that same pair. Merged by line as usual: a `mix.lock` where one side changed a git dependency and the other side changed any package, since the lockfile records nothing of what a git dependency requires; the rest of a `mix.exs` where both sides changed it; and a `deps` list not laid out as `mix format` writes it.\n- `hcl`: Merge a Terraform or OpenTofu configuration file (`.tf`, `.tofu`, `.tfvars`) by its syntax tree where git's line merge conflicts, so two pull requests adding different resources, variables, outputs or other blocks at the same place, different attributes to the same block, or different keys to the same map keep both: the batch's first, with the `=` columns `terraform fmt` aligns aligned again. The same attribute changed two ways (a version both pull requests bumped, a list both changed), a change to something the other side deleted, the same block or key added twice differently, two blocks of one type added to the same block (a provider may read their order), the same name declared twice in the file, a name one pull request deleted that the other's change refers to, two keys added to an object written on one line, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that is not a `.tf`, `.tofu` or `.tfvars` one (a Terragrunt or Packer `.hcl` file), does not parse, or is larger than 1 MiB, is merged by line as usual.\n- `haskell`: Merge a Haskell file (`.hs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, imported names, `LANGUAGE` pragmas, functions, types or instances at the same place keep both: the batch's first, or in the order the file keeps them sorted in. A function moves with its type signature, all its clauses and the pragmas naming it, and exports added by both pull requests are kept only at the end of the export list. A function whose code both pull requests changed (its signature on one side and a clause on the other included), the same name added twice, a change to something the other side deleted, a name one side removed that the other still uses, an import of a whole module one pull request removed or narrowed while the other added code reading a name the file does not define or import by name, declarations added at the same place as a Template Haskell splice, exports added at the same place anywhere but the end, an import or export list one pull request reformatted while the other changed it, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, uses the C preprocessor, or is larger than 2 MiB, is merged by line as usual.\n- `java`: Merge a Java file (`.java`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, types, methods, fields or tests at the same place keep both: the batch's first, with imports in the order the file keeps them, and a member's annotations and Javadoc moving with it. The same member changed two ways, a method whose signature one pull request changed and whose body the other did, a change to something the other side deleted, the same name declared twice (two overloads of one method or two constructors included), the overloads of one name each pull request changed its own way, a name one pull request imports that the other declares, an empty JDK collection one pull request creates that the other's import or nested class turns into another class, elements added at the same place whose order matters (an enum constant, a statement, an initializer block, a field whose initializer calls code, a field of a class Lombok builds a constructor of, a Spring `@Bean` method), two imports of one simple name, an import landing among imports of the other kind (static or not), an import one pull request deleted while the other reads its name (a wildcard one included), or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `toml`: Merge a TOML file by its tables and keys where git's line merge conflicts, so two pull requests adding or changing different keys of the same table, or adding different tables at the same place, keep both: the batch's first, or in order where the file keeps them sorted. The same key or array element changed two ways, a change to something the other side deleted, a key one pull request moved to another table while the other changed or removed it, the same key added twice differently, elements added at the same place of an array or an array of tables (two different bumps of one pinned dependency among them), a multi-line string both changed, a reordering, or a result that defines something twice or writes one comment twice are a conflict as usual. A merge git completes is left as git wrote it, unless it defines the same key or table twice -- one added by each pull request at either end of a table -- or leaves an array element with no comma before the next, which is a conflict too, and a file with an inline table or an array element spread over lines, a table standing apart from the array of tables it belongs to, or a Julia `Manifest.toml`, is merged by line as usual.\n\nA conflict on any other file still removes the pull request from the batch.", + "description": "How to merge a matching file when two pull requests of the same batch both change it. `union`, `ours` and `theirs` are git's names, and `ours` is always what the batch already holds, the base branch plus the pull requests queued ahead, and never the incoming pull request:\n\n- `union`: Keep both sides' lines where they conflict, the batch's first.\n- `ours`: Keep the batch's whole file and discard the incoming pull request's change to it, even where the two did not conflict.\n- `theirs`: Take the incoming pull request's whole file and discard the batch's, even where the two did not conflict.\n- `prefer-ours`: Merge normally, and keep the batch's side only on the lines that conflict -- its whole file when both sides added the file.\n- `prefer-theirs`: Merge normally, and keep the incoming pull request's side only on the lines that conflict -- its whole file when both sides added the file.\n- `json`: Merge a JSON file by its structure rather than by line, so changes to different keys or array elements merge even on adjacent lines, and neither side's change is discarded. Two different values for the same key, a change to a key the other side deleted, a key both sides added differently, two insertions at the same place in an array, or two changes to the same array element, even to different fields of it, are a conflict even where git's line merge would have been clean. Where git's line merge is clean and gives the same result, that text is used as is; otherwise the incoming pull request's changes are written into the batch's text as it wrote them, the rest keeps the batch's formatting and key order, and a change written in a style the batch's file does not use is a conflict. A file that is not valid JSON is merged by line as usual.\n- `pnpm`: Merge a `pnpm-lock.yaml` (lockfile version 9) entry by entry, so two pull requests updating two different dependencies merge even where their entries sit side by side, including when both moved peers of the same package. The same dependency updated to two versions, a package updated on one side while the other moved its peers, a dependency one side removed and the other updated, or a merged file whose entries refer to a package version it no longer has, are a conflict, even where git's line merge would have been clean. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A file that is not a version 9 lockfile is merged by line as usual.\n- `uv`: Merge a `uv.lock` and the `pyproject.toml` beside it entry by entry, so two pull requests updating two different dependencies merge in both files even on adjacent lines, and two adding different keys at the same place of a `pyproject.toml` table, such as two extras, keep both: the batch's first, or in order where the table keeps them sorted; in a table that is not, two added after one comment, which would be written twice, or where both removed a key, such as a table both renamed two ways, conflict. A conflict, even where git's line merge would have been clean: the same dependency updated to two versions; a dependency one pull request moved to another table while the other changed or removed it; a `uv.lock` package one side updated and the other changed, or one side changed while depending on a package the other side updated, since the lockfile records no version constraint to check the two against; and a merged `uv.lock` naming a package it no longer has, or holding one nothing uses. In a `pyproject.toml`, a list of requirements (`dependencies`, an extra, a dependency group, `[build-system]`'s `requires`) and a workspace's members keep each in its sorted place; an element of any other list, such as a test path or a Poetry version constraint, and a table of an array of tables, such as an index, are placed by their neighbours, so one replaced two ways, or two added at one place, conflict. An element of a list other than a workspace's that one pull request replaced and the other removed or replaced differently, such as a requirement swapped for two other packages, conflicts too. A file written in a shape uv does not write, such as a multi-line string, is merged by line as usual.\n- `rails-schema`: Merge a Rails `db/schema.rb` by line. When two pull requests that each add a migration both change its version line (`ActiveRecord::Schema[8.1].define(version: ...)`), keep the later version: what `rails db:migrate` writes once both migrations are applied. Any other conflict in the file, version lines written by two different Rails versions, or a version older than the one the file had before either change, is a conflict as usual.\n- `yarn`: Merge a `yarn.lock`, from yarn 1 or from yarn 2 and later, entry by entry, so two pull requests updating two different dependencies merge even where their entries sit side by side. The same dependency updated to two versions, a dependency one side removed and the other updated, the two sides holding different `__metadata`, or a merged file referring to a package version it no longer has, or holding one nothing uses, are a conflict, even where git's line merge would have been clean. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A file in neither yarn format is merged by line as usual.\n- `typescript`: Merge a TypeScript file (`.ts`, `.tsx`, `.mts`, `.cts`, `.d.ts`) or a JavaScript file (`.js`, `.jsx`, `.mjs`, `.cjs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, members, object keys, tests, cases of a test's `it.each([...])` table or JSX elements at the same place keep both: the batch's first, or in the order the file keeps them sorted in. The same declaration, statement or value changed two ways, a change to something the other side deleted, something one side moved and the other deleted or moved elsewhere, the same name added twice, statements added at the same place (in a function body, or a file's own, such as an `exports.name = ...` or a `require` call), declarations added at the same place that run code where they stand (a variable, a field or an object key whose value calls code, a decorated class), tests of a serial suite, table cases that run code or that the test's title numbers by their place (`%#`) or names alike, two enum members given the same value, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it declares a name twice in one scope with `let`, `const`, `class` or two imports -- the same constant added by both pull requests, one at each end of the file -- which is a conflict too, and a file that does not parse, is larger than 2 MiB, or is minified JavaScript (more than 110 characters a line on average) is merged by line as usual.\n- `rails-structure`: Merge the `schema_migrations` list Rails writes at the end of a `db/structure.sql`, so two pull requests that each add a migration merge even though both add a row at the same end of the list: it is written back with the migrations either side added and without those either side removed, sorted as Rails sorts it. The rest of the file is merged by line as usual, so the same table changed by both pull requests is still a conflict, and so are both sides re-sorting the list in opposite orders and a list left with no migration. A file without exactly one such list, as any other SQL file, is merged by line as usual.\n- `rust`: Merge a Rust file (`.rs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, items, methods, fields, enum variants, match arms or derives at the same place keep both: the batch's first, with imports and modules in rustfmt's order and layout. The same item or expression changed two ways, a change to something the other side deleted, the same name added twice, a macro both sides changed, items added at the same place whose order matters (a `macro_rules!`, a field of a `#[repr]` struct, a match arm with a guard), a match that would miss an enum variant the other side added, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it defines a name twice in one module, `impl`, struct or enum, or in two inherent `impl`s of one module written alike -- the same function added by both pull requests, one at each end of the file, not under two different `#[cfg]`s -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `python`: Merge a Python file (`.py`, `.pyi`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, tests, methods, string dictionary keys, keyword arguments or, in a `test_*.py` or `*_test.py` file, cases of a test's `@pytest.mark.parametrize` table (literals, with the ids it lists) at the same place keep both: the batch's first, and imports in the order isort and ruff write them, or the order the file already keeps where it plainly follows no sorter. Each keeps its own decorators, docstring, comments and indentation. A function both pull requests changed (but for a test each changed only cases of its table in, and different ones), table cases pytest names by their place (a dictionary, or a tuple that is the value of one argument, given no id) or would name alike, a case both changed, statements or class fields added at the same place, definitions or values whose decorators (other than a test's own marks, fixtures and patches, or, in a `test_*.py` or `*_test.py` file, the project's own that run nothing but values), defaults, annotations, operators or subscripts can run code, classes with a base that could register them, imports added to a section the file keeps sorted in an order other than isort's and ruff's own, a change to something the other side deleted, the same name added twice, a name one side removed that the other still uses, a block one side re-indented, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `yaml`: Merge a YAML file (`.yml`, `.yaml`) by its structure where git's line merge conflicts, so two pull requests adding different keys to a mapping keep both, the batch's first or in the order the mapping keeps its keys sorted in, and two adding items at the end of a sequence (a job's steps, a list of hosts) keep both, the batch's first, as do two changing different items of one (the action pinned on each of two neighbouring steps). An item holding a `name` (a step, a task, a container) is known by it, so two changing different entries of the same one keep both, unless one of them swapped entries the other kept for new ones (a task's module for a `block`). Each side's text is kept as it wrote it, comments included. The same key or item changed two ways, a change to something the other side deleted, the same key or name added twice, items added at the same place anywhere but the end of a sequence, an item both append among different ones, a document added, removed or replaced, an anchor one side changed while the other changed what refers to it, or a result that does not read back as both sides' changes are a conflict as usual. A merge git completes is left as git wrote it, unless it holds a key twice in one mapping -- the same key added by both pull requests, one at each end -- which is a conflict too, and a file that does not parse, is larger than 2 MiB, has more than 32,767 lines (16,383 with Windows line endings) or a longer line, or uses a list or an alias as a key is merged by line as usual. In Mergify's own configuration file, two rules or entries added at the same place, its end included, are a conflict in `pull_request_rules`, `queue_rules`, `priority_rules` and `conflict_resolvers`, whose order Mergify reads; two merge protections or two conditions added at the same place keep both; and two changing different entries of a rule keep both even where one swapped an entry for another.\n- `cargo`: Merge a `Cargo.lock` (lockfile version 3 or 4) and the `Cargo.toml` beside it entry by entry, so two pull requests updating or adding two different crates merge in both files even on adjacent lines, and two adding a crate to a workspace's `members`, or different keys at the same place of a `Cargo.toml` table, keep both: the batch's first, or in order where the list keeps them sorted; in a list that is not, two added after one comment, which would be written twice, or two `Cargo.toml` keys where both removed one, such as a target table both renamed two ways, conflict. A conflict, even where git's line merge would have been clean: the same crate updated to two versions or changed two ways, or moved to another table by one pull request and changed or removed by the other; a `Cargo.lock` package one side changed while depending on a crate the other side removed or moved to a lower version, since the lockfile records no version constraint to check the two against; the two sides holding different lockfile versions; and a merged `Cargo.lock` that is not what Cargo writes, naming a package it no longer has, holding one nothing uses, or two versions of a crate Cargo would resolve to one. An element of a `Cargo.toml` list other than a workspace's, such as a feature or a crate type, and a table of an array of tables, such as a `[[bin]]`, are placed by their neighbours, so one replaced two ways, or two added at one place, conflict, as does one that one pull request replaced and the other removed. A file written in a shape Cargo does not write, such as a multi-line string, or an older lockfile version, is merged by line as usual.\n- `npm`: Merge a `package-lock.json` or an `npm-shrinkwrap.json` (lockfile version 2 or 3) entry by entry, so two pull requests updating or adding two different dependencies merge even where their entries sit side by side. A conflict, even where git's line merge would have been clean: the same package changed two ways; a package one side changed and the other removed; the two sides holding different lockfile versions; and a merged file in which a dependency would resolve to a version outside its range that no side resolved it to, or in which npm would mark a package development-only, optional or unused otherwise than the side it comes from does. The `package.json` beside it usually conflicts too: a `package-manager: npm` entry resolves both. A version 1 lockfile, or a file laid out otherwise than npm writes it, is merged by line as usual.\n- `go`: Merge a Go file (`.go`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, functions, methods, types, struct fields, interface methods, constants, map keys or rows at the end of a test table at the same place keep both: the batch's first, with imports in gofmt's order and the lines laid out as gofmt aligns them. The same declaration or value changed two ways, a function or a test table row both pull requests changed, a change to something the other side deleted, the same name declared twice, two constants given the same value, declarations added at the same place whose order matters (an `init` function, an `iota` constant, a variable or key whose value calls code, a field of a struct with a padding field), table rows added at the same place anywhere but the end, an import left unused or a package left without its import, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it declares a name twice in one place -- the same type added by both pull requests, one at each end of the file -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `gomod`: Merge a `go.mod` and the `go.sum` beside it entry by entry, so two pull requests updating or adding two different modules merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same module updated to two versions or changed two ways, in either file. Neither file records why a module is required, so a module one pull request removed is removed even where the other pull request's change needs it, including on lines git's line merge would have conflicted on, and Go then refuses to build until `go mod tidy` puts it back. A `go.mod` with a quoted string or a directive Go does not know is merged by line as usual.\n- `sbt`: Merge an sbt build file (`build.sbt`, `project/*.sbt`, `project/*.scala`, `project/build.properties`) by line as git does, except that a change rewriting only versions never conflicts with the lines around it: two pull requests bumping dependencies on adjacent lines, or one bumping a dependency beside a line the other adds or removes, merge, each version taken from the pull request that changed it. A version is a double-quoted string that reads as one, or the value of `project/build.properties`' `sbt.version`. The same version changed two ways, and lines both pull requests changed otherwise, such as two dependencies added at one place or one appended to a `Seq(...)` whose last element the other bumped, are a conflict as usual. A merge git completes is left as git wrote it.\n- `terraform`: Merge a `.terraform.lock.hcl`, from Terraform or OpenTofu, provider by provider, so two pull requests updating or adding two different providers merge even on adjacent lines, and so do two pull requests locking one provider version for two platforms. A conflict, even where git's line merge would have been clean: the same provider changed by both to two versions or under two sets of constraints. The lock file does not record why a provider is required, so a provider one pull request removed is removed even where the other pull request's change needs it, including on lines git's line merge would have conflicted on, and `terraform init` then puts it back. A lock file either pull request wrote in a layout Terraform does not write, such as with a `module` block or a list on one line, is merged by line as usual.\n- `nix`: Merge a `flake.lock` (lockfile version 7) input by input, so two pull requests updating or adding two different inputs merge, even where an input one adds makes Nix rename the nodes the other updated. A conflict, even where git's line merge would have been clean: the same input locked two ways, or locked by one side and removed by the other; a merged `flake.lock` with a `follows` leading to no input or a node nothing uses; and a merge base not written as Nix writes one under two sides that are. Either side not written as Nix writes one, or in an older lockfile version, is merged by line as usual. The `flake.nix` beside it is not read.\n- `ruby`: Merge a Ruby file (`.rb`, `.rake`, `.gemspec`, `.ru`, `.rbi`, a `Gemfile` or a `Rakefile`) by its syntax tree where git's line merge conflicts, so two pull requests adding different methods, attributes, constants, classes, requires, tests, `let` helpers, gem specification dependencies or hash keys at the same place keep both: the batch's first, with requires kept in the order the file sorts them. The same definition or value changed two ways, a method or a block of code both pull requests changed, a change to something the other side deleted, the same name defined twice, constants written together changed differently (a version's `TINY` on one side and `PRE` on the other), statements and class-body calls added at the same place whose order matters (`include`, `has_many`, `validates`, a hook, a Gemfile's `gem`), a method one pull request deleted that the other one's change still calls, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `swift`: Merge a Swift file (`.swift`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, types, extensions, methods of different names, protocol requirements, enum cases or properties at the same place keep both: the batch's first, with imports kept sorted where the file sorts them. The same declaration changed two ways, a function both pull requests changed, a change to something the other side deleted, the same name declared twice or two overloads of one name (two initializers among them), declarations added at the same place whose order matters (a statement, a stored property or a global variable whose value runs code, the case of an enum numbered or listed by its order), two cases given the same raw value, a case one pull request added beside a `switch` over its enum with no `default` the other wrote, a `#if` left without its `#endif`, an import one pull request removed while the other changed the file, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, unless it redeclares something in one file or type -- the same method, with the same signature, added by both pull requests, one at each end of a type or one in each of two of its extensions that add no conformance, not under two different `#if`s -- which is a conflict too, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `mix`: Merge a `mix.lock` dependency by dependency, and the `deps` list of the `mix.exs` beside it element by element, so two pull requests updating or adding two different packages merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same package changed two ways; a package one side changed and the other removed; and a merged `mix.lock` in which a Hex package's dependency is no longer locked at a version its recorded requirement accepts, unless a side holds that same pair. Merged by line as usual: a `mix.lock` where one side changed a git dependency and the other side changed any package, since the lockfile records nothing of what a git dependency requires; the rest of a `mix.exs` where both sides changed it; and a `deps` list not laid out as `mix format` writes it.\n- `hcl`: Merge a Terraform or OpenTofu configuration file (`.tf`, `.tofu`, `.tfvars`) by its syntax tree where git's line merge conflicts, so two pull requests adding different resources, variables, outputs or other blocks at the same place, different attributes to the same block, or different keys to the same map keep both: the batch's first, with the `=` columns `terraform fmt` aligns aligned again. The same attribute changed two ways (a version both pull requests bumped, a list both changed), a change to something the other side deleted, the same block or key added twice differently, two blocks of one type added to the same block (a provider may read their order), the same name declared twice in the file, a name one pull request deleted that the other's change refers to, two keys added to an object written on one line, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that is not a `.tf`, `.tofu` or `.tfvars` one (a Terragrunt or Packer `.hcl` file), does not parse, or is larger than 1 MiB, is merged by line as usual.\n- `haskell`: Merge a Haskell file (`.hs`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, imported names, `LANGUAGE` pragmas, functions, types or instances at the same place keep both: the batch's first, or in the order the file keeps them sorted in. A function moves with its type signature, all its clauses and the pragmas naming it, and exports added by both pull requests are kept only at the end of the export list. A function whose code both pull requests changed (its signature on one side and a clause on the other included), the same name added twice, a change to something the other side deleted, a name one side removed that the other still uses, an import of a whole module one pull request removed or narrowed while the other added code reading a name the file does not define or import by name, declarations added at the same place as a Template Haskell splice, exports added at the same place anywhere but the end, an import or export list one pull request reformatted while the other changed it, or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, uses the C preprocessor, or is larger than 2 MiB, is merged by line as usual.\n- `java`: Merge a Java file (`.java`) by its syntax tree where git's line merge conflicts, so two pull requests adding different imports, types, methods, fields or tests at the same place keep both: the batch's first, with imports in the order the file keeps them, and a member's annotations and Javadoc moving with it. The same member changed two ways, a method whose signature one pull request changed and whose body the other did, a change to something the other side deleted, the same name declared twice (two overloads of one method or two constructors included), the overloads of one name each pull request changed its own way, a name one pull request imports that the other declares, an empty JDK collection one pull request creates that the other's import or nested class turns into another class, elements added at the same place whose order matters (an enum constant, a statement, an initializer block, a field whose initializer calls code, a field of a class Lombok builds a constructor of, a Spring `@Bean` method), two imports of one simple name, an import landing among imports of the other kind (static or not), an import one pull request deleted while the other reads its name (a wildcard one included), or a result that does not parse are a conflict as usual. A merge git completes is left as git wrote it, and a file that does not parse, or is larger than 2 MiB, is merged by line as usual.\n- `toml`: Merge a TOML file by its tables and keys where git's line merge conflicts, so two pull requests adding or changing different keys of the same table, or adding different tables at the same place, keep both: the batch's first, or in order where the file keeps them sorted. The same key or array element changed two ways, a change to something the other side deleted, a key one pull request moved to another table while the other changed or removed it, the same key added twice differently, elements added at the same place of an array or an array of tables (two different bumps of one pinned dependency among them), a multi-line string both changed, a reordering, or a result that defines something twice or writes one comment twice are a conflict as usual. A merge git completes is left as git wrote it, unless it defines the same key or table twice -- one added by each pull request at either end of a table -- or leaves an array element with no comma before the next, which is a conflict too, and a file with an inline table or an array element spread over lines, a table standing apart from the array of tables it belongs to, or a Julia `Manifest.toml`, is merged by line as usual.\n- `pip`: Merge a pip requirements file (a `requirements.txt`, or the `.in` pip-compile reads) requirement by requirement where git's line merge conflicts, so two pull requests updating two different dependencies merge even on adjacent lines, and two adding a requirement at the same place keep both: the batch's first, or in their sorted place where the file is sorted, as pip-compile writes it. A requirement's version and hashes go together, its `# via` lines and the comments above it apart. A merge git's line merge completes is kept as it is. Where it conflicts, still a conflict: the same package, or the options (`--index-url`, `-r` and the like), changed two ways, a URL naming a package by `#egg=` counting as that package; a URL or an editable naming no package beside any change of the other pull request; a package one pull request changed and the other removed; in a file pip-compile wrote, a package one side changed while depending on a package the other side moved, since the file records no version constraint to check the two against, and a merged file whose `# via` lines name a package it no longer holds. A file pip would not read is merged by line as usual.\n- `dockerfile`: Merge a Dockerfile or a Containerfile by its instructions where git's line merge conflicts, so two pull requests changing different instructions, or adding different packages to the same `RUN` -- an `apt-get install`, `apk add`, `pip install`, `npm install` or `install -t` list, each package on its own line or not -- keep both: the batch's first, or in order where the list is sorted, as Docker's best practices ask. A stage is known by its `AS` name, an `ARG`, `ENV` or `LABEL` by the names it sets. Two pull requests adding instructions at the same place (but for `ARG`, `ENV`, `LABEL` or `EXPOSE` ones reading no variable), the same instruction changed two ways (a `FROM` image bumped by both, by its tag or its digest), the same package changed two ways, a `RUN` command other than an install both changed, an option of an install either changed, a package added beside an option that may read it as its value, a command holding a variable or a redirection, or a heredoc, are a conflict as usual. A merge git completes is left as git wrote it, and a file with an `escape` parser directive, a file that does not parse, or one larger than 2 MiB, is merged by line as usual.\n- `xml`: Merge an XML file by its elements and attributes where git's line merge conflicts, so two pull requests changing different elements, or different attributes of one element, keep both, each written as that pull request wrote it, comments and spacing included. In a string table -- a .NET `.resx` or `.resw` file, an Android `res/values*/` file -- an entry is known by its name, and an Android resource by its type too, so two pull requests adding different entries at the same place keep both, the batch's first. Elsewhere, two pull requests adding elements at the same place, whose order a schema or a program may read, or each changing one of two elements of the same name, which are known by their text, the same element, attribute or text changed two ways, a change to something the other side deleted, an entry or attribute added twice differently, or a result holding an element one pull request moved and the other changed or deleted, are a conflict as usual. A merge git completes is left as git wrote it, unless it holds one attribute twice in a tag or one string table entry twice, which is a conflict too, and a file that does not parse as XML, or one larger than 2 MiB, is merged by line as usual.\n\nA conflict on any other file still removes the pull request from the batch.", "enum": [ "union", "ours", @@ -1093,7 +1093,10 @@ "hcl", "haskell", "java", - "toml" + "toml", + "pip", + "dockerfile", + "xml" ], "title": "Strategy", "type": "string", @@ -1201,7 +1204,7 @@ } }, { - "description": "Merge a `uv.lock` and the `pyproject.toml` beside it entry by entry, so two pull requests updating two different dependencies merge in both files even on adjacent lines. A conflict, even where git's line merge would have been clean: the same dependency updated to two versions; a dependency one pull request moved to another table while the other changed or removed it; a `uv.lock` package one side updated and the other changed, or one side changed while depending on a package the other side updated, since the lockfile records no version constraint to check the two against; and a merged `uv.lock` naming a package it no longer has, or holding one nothing uses. A file written in a shape uv does not write, such as a multi-line string, is merged by line as usual.", + "description": "Merge a `uv.lock` and the `pyproject.toml` beside it entry by entry, so two pull requests updating two different dependencies merge in both files even on adjacent lines, and two adding different keys at the same place of a `pyproject.toml` table, such as two extras, keep both: the batch's first, or in order where the table keeps them sorted; in a table that is not, two added after one comment, which would be written twice, or where both removed a key, such as a table both renamed two ways, conflict. A conflict, even where git's line merge would have been clean: the same dependency updated to two versions; a dependency one pull request moved to another table while the other changed or removed it; a `uv.lock` package one side updated and the other changed, or one side changed while depending on a package the other side updated, since the lockfile records no version constraint to check the two against; and a merged `uv.lock` naming a package it no longer has, or holding one nothing uses. In a `pyproject.toml`, a list of requirements (`dependencies`, an extra, a dependency group, `[build-system]`'s `requires`) and a workspace's members keep each in its sorted place; an element of any other list, such as a test path or a Poetry version constraint, and a table of an array of tables, such as an index, are placed by their neighbours, so one replaced two ways, or two added at one place, conflict. An element of a list other than a workspace's that one pull request replaced and the other removed or replaced differently, such as a requirement swapped for two other packages, conflicts too. A file written in a shape uv does not write, such as a multi-line string, is merged by line as usual.", "facts": { "detects_clean_merges": true, "discards": null, @@ -1315,7 +1318,7 @@ } }, { - "description": "Merge a `Cargo.lock` (lockfile version 3 or 4) and the `Cargo.toml` beside it entry by entry, so two pull requests updating or adding two different crates merge in both files even on adjacent lines, and two adding a crate to a workspace's `members` keep both. A conflict, even where git's line merge would have been clean: the same crate updated to two versions or changed two ways, or moved to another table by one pull request and changed or removed by the other; a `Cargo.lock` package one side changed while depending on a crate the other side removed or moved to a lower version, since the lockfile records no version constraint to check the two against; the two sides holding different lockfile versions; and a merged `Cargo.lock` that is not what Cargo writes, naming a package it no longer has, holding one nothing uses, or two versions of a crate Cargo would resolve to one. A file written in a shape Cargo does not write, such as a multi-line string, or an older lockfile version, is merged by line as usual.", + "description": "Merge a `Cargo.lock` (lockfile version 3 or 4) and the `Cargo.toml` beside it entry by entry, so two pull requests updating or adding two different crates merge in both files even on adjacent lines, and two adding a crate to a workspace's `members`, or different keys at the same place of a `Cargo.toml` table, keep both: the batch's first, or in order where the list keeps them sorted; in a list that is not, two added after one comment, which would be written twice, or two `Cargo.toml` keys where both removed one, such as a target table both renamed two ways, conflict. A conflict, even where git's line merge would have been clean: the same crate updated to two versions or changed two ways, or moved to another table by one pull request and changed or removed by the other; a `Cargo.lock` package one side changed while depending on a crate the other side removed or moved to a lower version, since the lockfile records no version constraint to check the two against; the two sides holding different lockfile versions; and a merged `Cargo.lock` that is not what Cargo writes, naming a package it no longer has, holding one nothing uses, or two versions of a crate Cargo would resolve to one. An element of a `Cargo.toml` list other than a workspace's, such as a feature or a crate type, and a table of an array of tables, such as a `[[bin]]`, are placed by their neighbours, so one replaced two ways, or two added at one place, conflict, as does one that one pull request replaced and the other removed. A file written in a shape Cargo does not write, such as a multi-line string, or an older lockfile version, is merged by line as usual.", "facts": { "detects_clean_merges": true, "discards": null, @@ -1512,6 +1515,48 @@ "toml" ] } + }, + { + "description": "Merge a pip requirements file (a `requirements.txt`, or the `.in` pip-compile reads) requirement by requirement where git's line merge conflicts, so two pull requests updating two different dependencies merge even on adjacent lines, and two adding a requirement at the same place keep both: the batch's first, or in their sorted place where the file is sorted, as pip-compile writes it. A requirement's version and hashes go together, its `# via` lines and the comments above it apart. A merge git's line merge completes is kept as it is. Where it conflicts, still a conflict: the same package, or the options (`--index-url`, `-r` and the like), changed two ways, a URL naming a package by `#egg=` counting as that package; a URL or an editable naming no package beside any change of the other pull request; a package one pull request changed and the other removed; in a file pip-compile wrote, a package one side changed while depending on a package the other side moved, since the file records no version constraint to check the two against, and a merged file whose `# via` lines name a package it no longer holds. A file pip would not read is merged by line as usual.", + "facts": { + "detects_clean_merges": true, + "discards": null, + "kind": "driver", + "options": {}, + "resolves_binary": false, + "resolves_clashes": false, + "suits": [ + "pip-requirements" + ] + } + }, + { + "description": "Merge a Dockerfile or a Containerfile by its instructions where git's line merge conflicts, so two pull requests changing different instructions, or adding different packages to the same `RUN` -- an `apt-get install`, `apk add`, `pip install`, `npm install` or `install -t` list, each package on its own line or not -- keep both: the batch's first, or in order where the list is sorted, as Docker's best practices ask. A stage is known by its `AS` name, an `ARG`, `ENV` or `LABEL` by the names it sets. Two pull requests adding instructions at the same place (but for `ARG`, `ENV`, `LABEL` or `EXPOSE` ones reading no variable), the same instruction changed two ways (a `FROM` image bumped by both, by its tag or its digest), the same package changed two ways, a `RUN` command other than an install both changed, an option of an install either changed, a package added beside an option that may read it as its value, a command holding a variable or a redirection, or a heredoc, are a conflict as usual. A merge git completes is left as git wrote it, and a file with an `escape` parser directive, a file that does not parse, or one larger than 2 MiB, is merged by line as usual.", + "facts": { + "detects_clean_merges": true, + "discards": null, + "kind": "driver", + "options": {}, + "resolves_binary": false, + "resolves_clashes": false, + "suits": [ + "dockerfile" + ] + } + }, + { + "description": "Merge an XML file by its elements and attributes where git's line merge conflicts, so two pull requests changing different elements, or different attributes of one element, keep both, each written as that pull request wrote it, comments and spacing included. In a string table -- a .NET `.resx` or `.resw` file, an Android `res/values*/` file -- an entry is known by its name, and an Android resource by its type too, so two pull requests adding different entries at the same place keep both, the batch's first. Elsewhere, two pull requests adding elements at the same place, whose order a schema or a program may read, or each changing one of two elements of the same name, which are known by their text, the same element, attribute or text changed two ways, a change to something the other side deleted, an entry or attribute added twice differently, or a result holding an element one pull request moved and the other changed or deleted, are a conflict as usual. A merge git completes is left as git wrote it, unless it holds one attribute twice in a tag or one string table entry twice, which is a conflict too, and a file that does not parse as XML, or one larger than 2 MiB, is merged by line as usual.", + "facts": { + "detects_clean_merges": true, + "discards": null, + "kind": "driver", + "options": {}, + "resolves_binary": false, + "resolves_clashes": false, + "suits": [ + "xml" + ] + } } ], "x-mergify-facts-vocabulary": { @@ -1529,6 +1574,7 @@ "append-only": "append-only files, such as a changelog", "cargo-lockfile": "Cargo lockfiles (`Cargo.lock`)", "cargo-manifest": "Cargo manifests (`Cargo.toml`)", + "dockerfile": "Dockerfiles and Containerfiles", "go": "Go files", "gomod-checksums": "Go checksum files (`go.sum`)", "gomod-manifest": "Go module files (`go.mod`)", @@ -1540,6 +1586,7 @@ "mix-manifest": "Mix project files (`mix.exs`)", "nix-lockfile": "Nix flake lockfiles (`flake.lock`)", "npm-lockfile": "npm lockfiles (`package-lock.json`, `npm-shrinkwrap.json`)", + "pip-requirements": "pip requirements files (`requirements.txt`), written by hand or by pip-compile", "pnpm-lockfile": "pnpm lockfiles (`pnpm-lock.yaml`)", "pyproject": "`pyproject.toml` files", "python": "Python files", @@ -1554,6 +1601,7 @@ "toml": "TOML files, such as a `rust-toolchain.toml` or a Gradle version catalog", "typescript": "TypeScript files", "uv-lockfile": "uv lockfiles (`uv.lock`)", + "xml": "XML files, such as a .NET `.resx` or an Android `res/values` string table", "yaml": "YAML files", "yarn-lockfile": "yarn lockfiles (`yarn.lock`)" } @@ -2100,7 +2148,7 @@ "additionalProperties": false, "properties": { "language": { - "description": "The language whose files to resolve, leaving Mergify to pick which files those are and how each merges, at any depth below each of the `directories` unless said otherwise. `typescript` resolves `*.{ts,tsx,mts,cts}` with the `typescript` strategy. `javascript` resolves `*.{js,jsx,mjs,cjs}` with the `typescript` strategy. `rust` resolves `*.rs` with the `rust` strategy. `python` resolves `*.{py,pyi}` with the `python` strategy. `yaml` resolves `*.{yml,yaml}` with the `yaml` strategy. `go` resolves `*.go` with the `go` strategy. `ruby` resolves `*.{rb,rake,gemspec,ru,rbi}`, `Gemfile` and `Rakefile` with the `ruby` strategy, `db/schema.rb` with the `rails-schema` strategy. `swift` resolves `*.swift` with the `swift` strategy. `terraform` resolves `*.{tf,tofu,tfvars}` with the `hcl` strategy. `haskell` resolves `*.hs` with the `haskell` strategy. `java` resolves `*.java` with the `java` strategy. `toml` resolves `*.toml` with the `toml` strategy. `github-actions` resolves `.github/workflows/*.{yml,yaml}` and `action.{yml,yaml}` with the `yaml` strategy. `mergify` resolves `.mergify.yml`, `.mergify.yaml`, `.mergify/config.yml`, `.mergify/config.yaml`, `.github/mergify.yml` and `.github/mergify.yaml` at the repository root, with the `yaml` strategy. The last entry matching a file wins, so a `package-manager` entry keeps its `pnpm-lock.yaml` from a `yaml` one by coming after it.", + "description": "The language whose files to resolve, leaving Mergify to pick which files those are and how each merges, at any depth below each of the `directories` unless said otherwise. `typescript` resolves `*.{ts,tsx,mts,cts}` with the `typescript` strategy. `javascript` resolves `*.{js,jsx,mjs,cjs}` with the `typescript` strategy. `rust` resolves `*.rs` with the `rust` strategy. `python` resolves `*.{py,pyi}` with the `python` strategy. `yaml` resolves `*.{yml,yaml}` with the `yaml` strategy. `go` resolves `*.go` with the `go` strategy. `ruby` resolves `*.{rb,rake,gemspec,ru,rbi}`, `Gemfile` and `Rakefile` with the `ruby` strategy, `db/schema.rb` with the `rails-schema` strategy. `swift` resolves `*.swift` with the `swift` strategy. `terraform` resolves `*.{tf,tofu,tfvars}` with the `hcl` strategy. `haskell` resolves `*.hs` with the `haskell` strategy. `java` resolves `*.java` with the `java` strategy. `toml` resolves `*.toml` with the `toml` strategy. `dockerfile` resolves `{Dockerfile,dockerfile,Containerfile,containerfile}`, `{Dockerfile,Containerfile}.*` and `*.{Dockerfile,dockerfile,Containerfile,containerfile}` with the `dockerfile` strategy. `xml` resolves `*.{xml,resx,resw}` with the `xml` strategy. `github-actions` resolves `.github/workflows/*.{yml,yaml}` and `action.{yml,yaml}` with the `yaml` strategy. `mergify` resolves `.mergify.yml`, `.mergify.yaml`, `.mergify/config.yml`, `.mergify/config.yaml`, `.github/mergify.yml` and `.github/mergify.yaml` at the repository root, with the `yaml` strategy. The last entry matching a file wins, so a `package-manager` entry keeps its `pnpm-lock.yaml` from a `yaml` one by coming after it.", "enum": [ "typescript", "javascript", @@ -2114,6 +2162,8 @@ "haskell", "java", "toml", + "dockerfile", + "xml", "github-actions", "mergify" ], @@ -2204,6 +2254,20 @@ }, "title": "TOML" }, + { + "description": "Resolves `{Dockerfile,dockerfile,Containerfile,containerfile}`, `{Dockerfile,Containerfile}.*` and `*.{Dockerfile,dockerfile,Containerfile,containerfile}` with the `dockerfile` strategy.", + "facts": { + "at_root": false + }, + "title": "Dockerfile" + }, + { + "description": "Resolves `*.{xml,resx,resw}` with the `xml` strategy.", + "facts": { + "at_root": false + }, + "title": "XML" + }, { "description": "Resolves `.github/workflows/*.{yml,yaml}` and `action.{yml,yaml}` with the `yaml` strategy.", "facts": { @@ -2549,11 +2613,21 @@ "title": "Status Comments", "type": "string" }, + "batch_pull_request": { + "default": true, + "title": "Batch Pull Request", + "type": "boolean", + "x-mergify-experimental": true + }, "queue_controls_comment": { "default": true, "description": "When enabled, Mergify renders task-list checkboxes a developer can tick instead of typing `@mergifyio queue`. The two controls live in different comments.\n- `Queue this pull request`: a comment of its own, posted before the pull request is queued.\n- `Requeue this pull request`: part of the Merge Queue status comment, after the pull request has left the queue, unless the queue merged it.\n", "title": "Queue Controls Comment", "type": "boolean" + }, + "resolve_conflicts": { + "$ref": "#/$defs/ResolveConflicts", + "x-mergify-experimental": true } }, "title": "MergeQueue", @@ -2600,7 +2674,7 @@ "additionalProperties": false, "properties": { "package-manager": { - "description": "The package manager whose manifest and lockfile to resolve, by the name Dependabot gives it, leaving Mergify to pick how each file merges: a `package-lock.json`, a `pnpm-lock.yaml`, a `yarn.lock`, a `uv.lock`, a `Cargo.lock`, a `go.sum`, a `.terraform.lock.hcl` or a `mix.lock` merges dependency by dependency, as does the manifest beside it where one is named below, and a dependency the two pull requests changed differently still conflicts. `npm` covers npm, pnpm and yarn alike, and resolves a `package-lock.json` or an `npm-shrinkwrap.json` (lockfile version 2 or 3), a `pnpm-lock.yaml`, or a `yarn.lock` from any yarn version. `uv` resolves a `pyproject.toml` and its `uv.lock`. `cargo` resolves a `Cargo.toml` and its `Cargo.lock`. Listing a workspace's root is enough for these three: the members its `Cargo.toml` (`[workspace]`), its `pyproject.toml` (`[tool.uv.workspace]`), its `package.json` (`workspaces`) or its `pnpm-workspace.yaml` (`packages`) declare on the base branch, globs and exclusions included as that package manager reads them, are resolved as if each member's directory were listed too. `gomod` resolves a `go.mod` and its `go.sum`: list each module's directory. `sbt` resolves a `build.sbt` and the `project/*.sbt`, `project/*.scala` and `project/build.properties` beside it by line, where a change rewriting only versions no longer conflicts with the lines around it: list the build's root, and each subproject whose own `build.sbt` two pull requests may both change. `terraform` and `opentofu` resolve the `.terraform.lock.hcl` of each listed directory, the root module's, and not the `.tf` files declaring its providers, which the `terraform` language resolves. `nix` resolves a `flake.lock` input by input: its `flake.nix` merges as usual. `mix` resolves a `mix.lock` and the dependency list of the `mix.exs` beside it: list an umbrella's root, and each app whose own `mix.exs` two pull requests may both change.", + "description": "The package manager whose manifest and lockfile to resolve, by the name Dependabot gives it, leaving Mergify to pick how each file merges: a `package-lock.json`, a `pnpm-lock.yaml`, a `yarn.lock`, a `uv.lock`, a `Cargo.lock`, a `go.sum`, a `.terraform.lock.hcl`, a `mix.lock` or a requirements file merges dependency by dependency, as does the manifest beside it where one is named below, and a dependency the two pull requests changed differently still conflicts. `npm` covers npm, pnpm and yarn alike, and resolves a `package-lock.json` or an `npm-shrinkwrap.json` (lockfile version 2 or 3), a `pnpm-lock.yaml`, or a `yarn.lock` from any yarn version. `uv` resolves a `pyproject.toml` and its `uv.lock`. `cargo` resolves a `Cargo.toml` and its `Cargo.lock`. Listing a workspace's root is enough for these three: the members its `Cargo.toml` (`[workspace]`), its `pyproject.toml` (`[tool.uv.workspace]`), its `package.json` (`workspaces`) or its `pnpm-workspace.yaml` (`packages`) declare on the base branch, globs and exclusions included as that package manager reads them, are resolved as if each member's directory were listed too. `gomod` resolves a `go.mod` and its `go.sum`: list each module's directory. `sbt` resolves a `build.sbt` and the `project/*.sbt`, `project/*.scala` and `project/build.properties` beside it by line, where a change rewriting only versions no longer conflicts with the lines around it: list the build's root, and each subproject whose own `build.sbt` two pull requests may both change. `terraform` and `opentofu` resolve the `.terraform.lock.hcl` of each listed directory, the root module's, and not the `.tf` files declaring its providers, which the `terraform` language resolves. `nix` resolves a `flake.lock` input by input: its `flake.nix` merges as usual. `mix` resolves a `mix.lock` and the dependency list of the `mix.exs` beside it: list an umbrella's root, and each app whose own `mix.exs` two pull requests may both change. `pip` resolves the `.txt` and `.in` files of each listed directory whose name holds `requirements`, and every `.txt` and `.in` file of the `requirements/` directory beside them, requirement by requirement, its `Pipfile` with the `toml` strategy, and its `pyproject.toml` with the `uv` strategy, as `uv` does, Poetry's tables included: a `Pipfile.lock` or a `poetry.lock` merges as usual.", "enum": [ "npm", "uv", @@ -2610,7 +2684,9 @@ "terraform", "opentofu", "nix", - "mix" + "mix", + "pip", + "docker" ], "title": "Package-Manager", "type": "string", @@ -2650,6 +2726,14 @@ { "description": "Resolves `mix.exs` and `mix.lock` with the `mix` strategy.", "title": "Mix" + }, + { + "description": "Resolves `*requirements*.{txt,in}` and `requirements/*.{txt,in}` with the `pip` strategy, `Pipfile` with the `toml` strategy, `pyproject.toml` with the `uv` strategy. It covers pip-compile, Pipenv and Poetry projects alike, and a `Pipfile.lock` or a `poetry.lock` still merges as usual.", + "title": "pip" + }, + { + "description": "Resolves `{Dockerfile,dockerfile,Containerfile,containerfile}`, `{Dockerfile,Containerfile}.*` and `*.{Dockerfile,dockerfile,Containerfile,containerfile}` with the `dockerfile` strategy.", + "title": "Docker" } ] }, @@ -2777,7 +2861,7 @@ }, "allow_checks_interruption": { "default": false, - "description": "Allow interrupting the ongoing checks when the pull request entering the queue has a higher priority than the queued one(s). If set to false, a pull request with higher priority will be inserted just after the pull requests that have checks running.", + "description": "Allow interrupting the ongoing checks when the pull request entering the queue has a higher priority than the queued one(s). If set to false, a pull request with higher priority will be inserted just after the pull requests that have checks running. Whatever this setting, when every check slot is taken, checks a batch runs ahead of its merge schedule, while that schedule is closed, can give their check slot to a pull request whose merge schedule is open.", "title": "Allow Checks Interruption", "type": "boolean" } @@ -3363,7 +3447,8 @@ "CHECKS_INTERRUPTED", "GITHUB_WORKFLOWS_PERMISSION_MISSING", "BATCH_REBUILT", - "BATCH_AHEAD_REBUILT" + "BATCH_AHEAD_REBUILT", + "GITHUB_REBASE_MERGE_REFUSED" ], "type": "string" }, @@ -3488,7 +3573,7 @@ "description": "The pull request's failed checks are being retried. It stays in the queue." }, { - "description": "A pull request ahead that was waiting for its merge schedule yielded its position so ready pull requests behind it can merge first. It stays in the queue." + "description": "A pull request ahead or in the same batch that was waiting for its merge schedule yielded its position, or the check slot it was using ahead of time, so ready pull requests can merge first. It stays in the queue." }, { "description": "The pull request could not be retargeted onto the queue base branch, for example a stacked pull request GitHub never retargeted." @@ -3513,6 +3598,9 @@ }, { "description": "A batch ahead in the queue was torn down to be rebuilt, so this pull request's speculative checks are restarted. It stays in the queue." + }, + { + "description": "GitHub refuses to rebase-merge the pull request: one of its commits does not apply on the base branch, its commits do not end on the result of merging it, or it has more than 100 commits." } ], "x-mergify-has-data-type": true, @@ -5548,6 +5636,29 @@ "title": "RequestReviewsActionModel", "type": "object" }, + "ResolveConflicts": { + "additionalProperties": false, + "properties": { + "pull_requests": { + "default": "none", + "enum": [ + "none", + "queueable", + "all" + ], + "title": "Pull Requests", + "type": "string" + }, + "comment": { + "default": true, + "title": "Comment", + "type": "boolean" + } + }, + "title": "ResolveConflicts", + "type": "object", + "x-mergify-experimental": true + }, "ReviewActionModel": { "additionalProperties": false, "properties": { @@ -5698,7 +5809,7 @@ } ], "default": null, - "description": "Where scopes come from. `files` derives scopes from the pull request's changed files using file-pattern rules; `manual` uses scopes sent via API or `mergify scopes-send`; `None` disables scoping.", + "description": "Where scopes come from. `files` derives scopes from the pull request's changed files using file-pattern rules; `manual` uses scopes sent via API or `mergify ci scopes-send`; leaving it unset (or `null`) disables scoping.", "title": "Source" }, "barrier_files": { @@ -5727,7 +5838,7 @@ "minimum": 1, "type": "integer" }, - "description": "How many speculative checks each scope may run at the same time, as a map of scope name to capacity. Works for any `source` (file globs or the manual scopes API just decide membership; capacity is declared here). With a `manual` source a key may be any scope name the scopes API accepts, such as `//lib/core` or `@acme/web`; with any other source a key that is not a pattern must be a valid scope name. A key containing `*`, `?`, `[` or `{` is a glob pattern with the syntax of `files` filters, such as `@acme/*` or `//lib/**`: `*` and `?` stay within one `/`-separated segment and only a whole `**` segment crosses them, so `//lib/**` matches the packages below `//lib` but not `//lib` itself. In YAML, quote any key starting with `@`, `*`, `?`, `[` or `{`. A pattern gives every scope it matches its own budget, not one budget shared by all of them. A key equal to a scope's name wins over any pattern; when several patterns match a scope, the smallest capacity applies; `default_capacity` only covers scopes no key matches. A PR in several capped scopes consumes one slot from each. PRs whose scopes match no key share the repo-wide `merge_queue.max_parallel_checks` pool, unless `default_capacity` gives every scope a budget. Strict branch protection still forces an effective capacity of 1.", + "description": "How many speculative checks each scope may run at the same time, as a map of scope name to capacity. Works for any `source` (file globs or the manual scopes API just decide membership; capacity is declared here). With a `manual` source a key may be any scope name the scopes API accepts, such as `//lib/core` or `@acme/web`; with any other source a key that is not a pattern must be a valid scope name. A key containing `*`, `?`, `[` or `{` is a glob pattern with the syntax of `files` filters, such as `@acme/*` or `//lib/**`: `*` and `?` stay within one `/`-separated segment and only a whole `**` segment crosses them, so `//lib/**` matches the packages below `//lib` but not `//lib` itself. In YAML, quote any key starting with `@`, `*`, `?`, `[` or `{`. A pattern gives every scope it matches its own budget, not one budget shared by all of them. A key equal to a scope's name wins over any pattern; when several patterns match a scope, the smallest capacity applies; `default_capacity` only covers scopes no key matches. A PR in several capped scopes consumes one slot from each. PRs whose scopes match no key share the repo-wide `merge_queue.max_parallel_checks` pool, unless `default_capacity` gives every scope a budget. In `serial` mode, PRs queued behind one waiting for room in its scope can go ahead of it when they fit, and merge before it. Strict branch protection still forces an effective capacity of 1.", "propertyNames": { "maxLength": 1024 }, @@ -5746,7 +5857,7 @@ } ], "default": null, - "description": "How many speculative checks a scope that no `capacities` key matches may run at the same time. Applies to every scope observed on queued pull requests, so dynamic scope sets (e.g. sent by a monorepo build tool through the manual scopes API) get a per-scope budget without enumerating names; a matching `capacities` key or pattern still wins for its scope. `merge_queue.max_parallel_checks` remains the global ceiling on the total. When unset, scopes no `capacities` key matches are unlimited, and pull requests with no scopes always draw from the repo-wide pool. Strict branch protection still forces an effective capacity of 1.", + "description": "How many speculative checks a scope that no `capacities` key matches may run at the same time. Applies to every scope observed on queued pull requests, so dynamic scope sets (e.g. sent by a monorepo build tool through the manual scopes API) get a per-scope budget without enumerating names; a matching `capacities` key or pattern still wins for its scope. `merge_queue.max_parallel_checks` remains the global ceiling on the total. When unset, scopes no `capacities` key matches are unlimited, and pull requests with no scopes always draw from the repo-wide pool. In `serial` mode, PRs can go ahead of one waiting for room in its scope, as with `capacities`. Strict branch protection still forces an effective capacity of 1.", "title": "Default Capacity" } }, @@ -5780,7 +5891,7 @@ "additionalProperties": false, "properties": { "manual": { - "description": "Scopes are manually sent via API or `mergify scopes-send`", + "description": "Scopes are manually sent via API or `mergify ci scopes-send`", "title": "Manual", "type": "null" } diff --git a/src/check_jsonschema/builtin_schemas/vendor/renovate.json b/src/check_jsonschema/builtin_schemas/vendor/renovate.json index 02f9be0e5..711b47b23 100644 --- a/src/check_jsonschema/builtin_schemas/vendor/renovate.json +++ b/src/check_jsonschema/builtin_schemas/vendor/renovate.json @@ -1,8 +1,8 @@ { "$id": "https://docs.renovatebot.com/renovate-schema.json", - "title": "JSON schema for Renovate 44.181.5 config files (https://renovatebot.com/)", + "title": "JSON schema for Renovate 44.199.0 config files (https://renovatebot.com/)", "$schema": "http://json-schema.org/draft-07/schema#", - "x-renovate-version": "44.181.5", + "x-renovate-version": "44.199.0", "allowComments": true, "type": "object", "definitions": { @@ -8276,6 +8276,7 @@ "major", "minor", "patch", + "prerelease", "sync" ] }, @@ -13803,6 +13804,10 @@ "type": "string", "description": "A constraint for the `npm` Containerbase tool" }, + "paket": { + "type": "string", + "description": "A constraint for the `paket` Containerbase tool" + }, "pdm": { "type": "string", "description": "A constraint for the `pdm` Containerbase tool" @@ -19919,6 +19924,7 @@ "nvm", "ocb", "osgi", + "paket", "pep621", "pep723", "pip-compile", @@ -35907,6 +35913,7 @@ "nvm", "ocb", "osgi", + "paket", "pep621", "pep723", "pip-compile", @@ -36039,6 +36046,7 @@ "nvm", "ocb", "osgi", + "paket", "pep621", "pep723", "pip-compile", @@ -43445,6 +43453,478 @@ ] } }, + "paket": { + "description": "Configuration object for the paket manager\nSee also: https://docs.renovatebot.com/configuration-options/#paket", + "markdownDescription": "Configuration object for the paket manager\n\nSee also: [paket](https://docs.renovatebot.com/configuration-options/#paket)", + "type": "object", + "default": { + "managerFilePatterns": [ + "/(^|/)paket\\.dependencies$/" + ], + "versioning": "paket" + }, + "$ref": "#", + "allOf": [ + { + "type": "object", + "properties": { + "abandonmentThreshold": { + "$ref": "#/definitions/abandonmentThreshold" + }, + "addLabels": { + "$ref": "#/definitions/addLabels" + }, + "additionalBranchPrefix": { + "$ref": "#/definitions/additionalBranchPrefix" + }, + "additionalReviewers": { + "$ref": "#/definitions/additionalReviewers" + }, + "assignAutomerge": { + "$ref": "#/definitions/assignAutomerge" + }, + "assignees": { + "$ref": "#/definitions/assignees" + }, + "assigneesFromCodeOwners": { + "$ref": "#/definitions/assigneesFromCodeOwners" + }, + "assigneesSampleSize": { + "$ref": "#/definitions/assigneesSampleSize" + }, + "autoApprove": { + "$ref": "#/definitions/autoApprove" + }, + "autoReplaceGlobalMatch": { + "$ref": "#/definitions/autoReplaceGlobalMatch" + }, + "automerge": { + "$ref": "#/definitions/automerge" + }, + "automergeComment": { + "$ref": "#/definitions/automergeComment" + }, + "automergeSchedule": { + "$ref": "#/definitions/automergeSchedule" + }, + "automergeStrategy": { + "$ref": "#/definitions/automergeStrategy" + }, + "automergeType": { + "$ref": "#/definitions/automergeType" + }, + "azureWorkItemId": { + "$ref": "#/definitions/azureWorkItemId" + }, + "bbAutoResolvePrTasks": { + "$ref": "#/definitions/bbAutoResolvePrTasks" + }, + "bbUseDefaultReviewers": { + "$ref": "#/definitions/bbUseDefaultReviewers" + }, + "branchConcurrentLimit": { + "$ref": "#/definitions/branchConcurrentLimit" + }, + "branchName": { + "$ref": "#/definitions/branchName" + }, + "branchNameStrict": { + "$ref": "#/definitions/branchNameStrict" + }, + "branchPrefix": { + "$ref": "#/definitions/branchPrefix" + }, + "branchPrefixOld": { + "$ref": "#/definitions/branchPrefixOld" + }, + "branchTopic": { + "$ref": "#/definitions/branchTopic" + }, + "bumpVersion": { + "$ref": "#/definitions/bumpVersion" + }, + "bumpVersions": { + "$ref": "#/definitions/bumpVersions" + }, + "commitBody": { + "$ref": "#/definitions/commitBody" + }, + "commitBodyTable": { + "$ref": "#/definitions/commitBodyTable" + }, + "commitHourlyLimit": { + "$ref": "#/definitions/commitHourlyLimit" + }, + "commitMessage": { + "$ref": "#/definitions/commitMessage" + }, + "commitMessageAction": { + "$ref": "#/definitions/commitMessageAction" + }, + "commitMessageExtra": { + "$ref": "#/definitions/commitMessageExtra" + }, + "commitMessageLowerCase": { + "$ref": "#/definitions/commitMessageLowerCase" + }, + "commitMessagePrefix": { + "$ref": "#/definitions/commitMessagePrefix" + }, + "commitMessageSuffix": { + "$ref": "#/definitions/commitMessageSuffix" + }, + "commitMessageTopic": { + "$ref": "#/definitions/commitMessageTopic" + }, + "commitTrailers": { + "$ref": "#/definitions/commitTrailers" + }, + "composerIgnorePlatformReqs": { + "$ref": "#/definitions/composerIgnorePlatformReqs" + }, + "constraints": { + "$ref": "#/definitions/constraints" + }, + "constraintsFiltering": { + "$ref": "#/definitions/constraintsFiltering" + }, + "constraintsVersioning": { + "$ref": "#/definitions/constraintsVersioning" + }, + "customDatasources": { + "$ref": "#/definitions/customDatasources" + }, + "defaultRegistryUrls": { + "$ref": "#/definitions/defaultRegistryUrls" + }, + "dependencyDashboardApproval": { + "$ref": "#/definitions/dependencyDashboardApproval" + }, + "dependencyDashboardCategory": { + "$ref": "#/definitions/dependencyDashboardCategory" + }, + "description": { + "$ref": "#/definitions/description" + }, + "digest": { + "$ref": "#/definitions/digest" + }, + "draftPR": { + "$ref": "#/definitions/draftPR" + }, + "enabled": { + "$ref": "#/definitions/enabled" + }, + "encrypted": { + "$ref": "#/definitions/encrypted" + }, + "excludeCommitPaths": { + "$ref": "#/definitions/excludeCommitPaths" + }, + "expandCodeOwnersGroups": { + "$ref": "#/definitions/expandCodeOwnersGroups" + }, + "extends": { + "$ref": "#/definitions/extends" + }, + "extractVersion": { + "$ref": "#/definitions/extractVersion" + }, + "filterUnavailableUsers": { + "$ref": "#/definitions/filterUnavailableUsers" + }, + "followTag": { + "$ref": "#/definitions/followTag" + }, + "forkModeDisallowMaintainerEdits": { + "$ref": "#/definitions/forkModeDisallowMaintainerEdits" + }, + "gitLabIgnoreApprovals": { + "$ref": "#/definitions/gitLabIgnoreApprovals" + }, + "goGetDirs": { + "$ref": "#/definitions/goGetDirs" + }, + "group": { + "$ref": "#/definitions/group" + }, + "groupName": { + "$ref": "#/definitions/groupName" + }, + "groupSingleUpdates": { + "$ref": "#/definitions/groupSingleUpdates" + }, + "groupSlug": { + "$ref": "#/definitions/groupSlug" + }, + "hashedBranchLength": { + "$ref": "#/definitions/hashedBranchLength" + }, + "ignoreDeprecated": { + "$ref": "#/definitions/ignoreDeprecated" + }, + "ignoreDeps": { + "$ref": "#/definitions/ignoreDeps" + }, + "ignorePaths": { + "$ref": "#/definitions/ignorePaths" + }, + "ignorePlugins": { + "$ref": "#/definitions/ignorePlugins" + }, + "ignorePresets": { + "$ref": "#/definitions/ignorePresets" + }, + "ignoreReviewers": { + "$ref": "#/definitions/ignoreReviewers" + }, + "ignoreScripts": { + "$ref": "#/definitions/ignoreScripts" + }, + "ignoreTests": { + "$ref": "#/definitions/ignoreTests" + }, + "ignoreUnstable": { + "$ref": "#/definitions/ignoreUnstable" + }, + "includePaths": { + "$ref": "#/definitions/includePaths" + }, + "internalChecksAsSuccess": { + "$ref": "#/definitions/internalChecksAsSuccess" + }, + "internalChecksFilter": { + "$ref": "#/definitions/internalChecksFilter" + }, + "keepUpdatedLabel": { + "$ref": "#/definitions/keepUpdatedLabel" + }, + "labels": { + "$ref": "#/definitions/labels" + }, + "lockFileMaintenance": { + "$ref": "#/definitions/lockFileMaintenance" + }, + "major": { + "$ref": "#/definitions/major" + }, + "managerFilePatterns": { + "$ref": "#/definitions/managerFilePatterns" + }, + "maxMajorIncrement": { + "$ref": "#/definitions/maxMajorIncrement" + }, + "milestone": { + "$ref": "#/definitions/milestone" + }, + "minimumGroupSize": { + "$ref": "#/definitions/minimumGroupSize" + }, + "minimumReleaseAge": { + "$ref": "#/definitions/minimumReleaseAge" + }, + "minimumReleaseAgeBehaviour": { + "$ref": "#/definitions/minimumReleaseAgeBehaviour" + }, + "minimumReleaseAgeBuffer": { + "$ref": "#/definitions/minimumReleaseAgeBuffer" + }, + "minor": { + "$ref": "#/definitions/minor" + }, + "mode": { + "$ref": "#/definitions/mode" + }, + "npmrc": { + "$ref": "#/definitions/npmrc" + }, + "npmrcMerge": { + "$ref": "#/definitions/npmrcMerge" + }, + "overrideDescription": { + "$ref": "#/definitions/overrideDescription" + }, + "packageRules": { + "$ref": "#/definitions/packageRules" + }, + "patch": { + "$ref": "#/definitions/patch" + }, + "pin": { + "$ref": "#/definitions/pin" + }, + "pinDigest": { + "$ref": "#/definitions/pinDigest" + }, + "pinDigests": { + "$ref": "#/definitions/pinDigests" + }, + "platformAutomerge": { + "$ref": "#/definitions/platformAutomerge" + }, + "platformCommit": { + "$ref": "#/definitions/platformCommit" + }, + "postUpdateOptions": { + "$ref": "#/definitions/postUpdateOptions" + }, + "postUpgradeTasks": { + "$ref": "#/definitions/postUpgradeTasks" + }, + "prBodyColumns": { + "$ref": "#/definitions/prBodyColumns" + }, + "prBodyDefinitions": { + "$ref": "#/definitions/prBodyDefinitions" + }, + "prBodyHeadingDefinitions": { + "$ref": "#/definitions/prBodyHeadingDefinitions" + }, + "prBodyNotes": { + "$ref": "#/definitions/prBodyNotes" + }, + "prBodyTemplate": { + "$ref": "#/definitions/prBodyTemplate" + }, + "prConcurrentLimit": { + "$ref": "#/definitions/prConcurrentLimit" + }, + "prCreation": { + "$ref": "#/definitions/prCreation" + }, + "prFooter": { + "$ref": "#/definitions/prFooter" + }, + "prHeader": { + "$ref": "#/definitions/prHeader" + }, + "prHourlyLimit": { + "$ref": "#/definitions/prHourlyLimit" + }, + "prNotPendingHours": { + "$ref": "#/definitions/prNotPendingHours" + }, + "prTitle": { + "$ref": "#/definitions/prTitle" + }, + "prTitleStrict": { + "$ref": "#/definitions/prTitleStrict" + }, + "pruneBranchAfterAutomerge": { + "$ref": "#/definitions/pruneBranchAfterAutomerge" + }, + "rangeStrategy": { + "$ref": "#/definitions/rangeStrategy" + }, + "rebaseLabel": { + "$ref": "#/definitions/rebaseLabel" + }, + "rebaseWhen": { + "$ref": "#/definitions/rebaseWhen" + }, + "recreateWhen": { + "$ref": "#/definitions/recreateWhen" + }, + "registryAliases": { + "$ref": "#/definitions/registryAliases" + }, + "registryUrls": { + "$ref": "#/definitions/registryUrls" + }, + "replacement": { + "$ref": "#/definitions/replacement" + }, + "replacementApproach": { + "$ref": "#/definitions/replacementApproach" + }, + "respectLatest": { + "$ref": "#/definitions/respectLatest" + }, + "reviewers": { + "$ref": "#/definitions/reviewers" + }, + "reviewersFromCodeOwners": { + "$ref": "#/definitions/reviewersFromCodeOwners" + }, + "reviewersSampleSize": { + "$ref": "#/definitions/reviewersSampleSize" + }, + "rollback": { + "$ref": "#/definitions/rollback" + }, + "rollbackPrs": { + "$ref": "#/definitions/rollbackPrs" + }, + "schedule": { + "$ref": "#/definitions/schedule" + }, + "semanticCommitScope": { + "$ref": "#/definitions/semanticCommitScope" + }, + "semanticCommitType": { + "$ref": "#/definitions/semanticCommitType" + }, + "semanticCommits": { + "$ref": "#/definitions/semanticCommits" + }, + "separateMajorMinor": { + "$ref": "#/definitions/separateMajorMinor" + }, + "separateMinorPatch": { + "$ref": "#/definitions/separateMinorPatch" + }, + "separateMultipleMajor": { + "$ref": "#/definitions/separateMultipleMajor" + }, + "separateMultipleMinor": { + "$ref": "#/definitions/separateMultipleMinor" + }, + "skipArtifactsUpdate": { + "$ref": "#/definitions/skipArtifactsUpdate" + }, + "skipInstalls": { + "$ref": "#/definitions/skipInstalls" + }, + "statusCheckNames": { + "$ref": "#/definitions/statusCheckNames" + }, + "statusCheckWhen": { + "$ref": "#/definitions/statusCheckWhen" + }, + "stopUpdatingLabel": { + "$ref": "#/definitions/stopUpdatingLabel" + }, + "suppressNotifications": { + "$ref": "#/definitions/suppressNotifications" + }, + "timezone": { + "$ref": "#/definitions/timezone" + }, + "toolSettings": { + "$ref": "#/definitions/toolSettings" + }, + "updateInternalDeps": { + "$ref": "#/definitions/updateInternalDeps" + }, + "updateNotScheduled": { + "$ref": "#/definitions/updateNotScheduled" + }, + "updatePinnedDependencies": { + "$ref": "#/definitions/updatePinnedDependencies" + }, + "userStrings": { + "$ref": "#/definitions/userStrings" + }, + "versionCompatibility": { + "$ref": "#/definitions/versionCompatibility" + }, + "versioning": { + "$ref": "#/definitions/versioning" + } + } + } + ] + }, "patch": { "description": "Configuration to apply when an update type is `patch`.\nSee also: https://docs.renovatebot.com/configuration-options/#patch", "markdownDescription": "Configuration to apply when an update type is `patch`.\n\nSee also: [patch](https://docs.renovatebot.com/configuration-options/#patch)", @@ -65057,6 +65537,9 @@ "packageRules": { "$ref": "#/definitions/packageRules" }, + "paket": { + "$ref": "#/definitions/paket" + }, "patch": { "$ref": "#/definitions/patch" }, diff --git a/src/check_jsonschema/builtin_schemas/vendor/sha256/mergify.sha256 b/src/check_jsonschema/builtin_schemas/vendor/sha256/mergify.sha256 index f742b10e9..8513fbfa6 100644 --- a/src/check_jsonschema/builtin_schemas/vendor/sha256/mergify.sha256 +++ b/src/check_jsonschema/builtin_schemas/vendor/sha256/mergify.sha256 @@ -1 +1 @@ -4774c98030acea051a951c4371f7ffcb9962f1d3c590379b77c13ab728b9ead3 \ No newline at end of file +7e093d3ad265febddbac7f0b07d29e8b62302bf34b1a9ad5019a776223fe023b \ No newline at end of file diff --git a/src/check_jsonschema/builtin_schemas/vendor/sha256/renovate.sha256 b/src/check_jsonschema/builtin_schemas/vendor/sha256/renovate.sha256 index 1f103e544..c97720e33 100644 --- a/src/check_jsonschema/builtin_schemas/vendor/sha256/renovate.sha256 +++ b/src/check_jsonschema/builtin_schemas/vendor/sha256/renovate.sha256 @@ -1 +1 @@ -8310e7b51da681b60e553c52b42eaa72ab8baf1388ccaf598aaedb6d881d8db8 \ No newline at end of file +b3bdda9fa7d2d9c7b5a6785ab9e3fc36bcc7adb24db393e1683a6bc45609a9ab \ No newline at end of file