Update json_schemer requirement from >= 0.2.1, < 2.0.1 to >= 0.2.1, < 2.1.2

[dependabot]

Updates the requirements on json_schemer to permit the latest version.

Changelog

Sourced from json_schemer's changelog.

2.1.1 - 2023-11-28

Bug Fixes

• Fix refs to/through keyword objects: davishmcclurg/json_schemer#160
• Temporary fix for incorrect uri-reference format in OpenAPI 3.x: davishmcclurg/json_schemer#161

2.1.0 - 2023-11-17

Bug Fixes

• Limit anyOf/oneOf discriminator to listed refs: davishmcclurg/json_schemer#145
• Require discriminator propertyName property: davishmcclurg/json_schemer#145
• Support Schema#ref in subschemas: davishmcclurg/json_schemer#145
• Resolve JSON pointer refs using correct base URI: davishmcclurg/json_schemer#147
• date format in OpenAPI 3.0: davishmcclurg/json_schemer@69fe7a8

Features

• Custom error messages with x-error keyword and I18n: davishmcclurg/json_schemer#149
• Custom content encodings and media types: davishmcclurg/json_schemer#148

2.0.0 - 2023-08-20

For 2.0.0, much of the codebase was rewritten to simplify support for the two new JSON Schema draft versions (2019-09 and 2020-12). The major change is moving each keyword into its own class and organizing them into vocabularies. Output formats and annotations from the new drafts are also supported. The known breaking changes are listed below, but there may be others that haven't been identified.

Breaking Changes

• The default meta schema is now Draft 2020-12. Other meta schemas can be specified using meta_schema.
• Schemas use json-schemer://schema as the default base URI. Relative $id and $ref values are joined to the default base URI and are always absolute. For example, the schema { '$id' => 'foo', '$ref' => 'bar' } uses json-schemer://schema/foo as the base URI and passes json-schemer://schema/bar to the ref resolver. For relative refs, URI#path can be used in the ref resolver to access the relative portion, ie: URI('json-schemer://schema/bar').path => "/bar".
• Property validation hooks (before_property_validation and after_property_validation) run immediately before and after properties validation. Previously, before_property_validation ran before all "object" validations (dependencies, patternProperties, additionalProperties, etc) and after_property_validation was called after them.
• insert_property_defaults now inserts defaults in conditional subschemas when possible (if there's only one default or if there's only one unique default from a valid subtree).
• Error output
  • Special characters in schema_pointer are no longer percent encoded (eg, definitions/foo\"bar instead of /definitions/foo%22bar)
  • Keyword validation order changed so errors may be returned in a different order (eg, items errors before contains).
  • Array dependencies return "type": "dependencies" errors instead of "required" and point to the schema that contains the dependencies keyword.
  • not errors point to the schema that contains the not keyword (instead of the schema defined by the not keyword).
  • Custom keyword errors are now always wrapped in regular error hashes. Returned strings are used to set type:

    >> JSONSchemer.schema({ 'x' => 'y' }, :keywords => { 'x' => proc { false } }).validate({}).to_a
    => [{"data"=>{}, "data_pointer"=>"", "schema"=>{"x"=>"y"}, "schema_pointer"=>"", "root_schema"=>{"x"=>"y"}, "type"=>"x"}]
    >> JSONSchemer.schema({ 'x' => 'y' }, :keywords => { 'x' => proc { 'wrong!' } }).validate({}).to_a
    => [{"data"=>{}, "data_pointer"=>"", "schema"=>{"x"=>"y"}, "schema_pointer"=>"", "root_schema"=>{"x"=>"y"}, "type"=>"wrong!"}]
    

... (truncated)

Commits

• 9809d60 2.1.1
• 9497c08 Add date for 2.1.0 release
• d4f3fa8 Merge pull request #161 from davishmcclurg/openapi-uri-reference
• 1b05686 Merge pull request #160 from davishmcclurg/keyword-ref
• 8492b6d Fix keyword refs
• 4fdbf0c Drop incorrect uri-reference OpenAPI formats
• f48c563 Merge pull request #156 from davishmcclurg/2.1.0
• a47f148 Update fixtures
• 052cb8b Merge commit '8c77a4278e0b09e2664d387267f88005497cf048' into 2.1.0
• 8c77a42 Squashed 'JSON-Schema-Test-Suite/' changes from 5cc9214e..d38ddd54
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[chef-expeditor]

Hello dependabot[bot]! Thanks for the pull request!

Here is what will happen next:

1. Your PR will be reviewed by the maintainers.
2. Possible Outcomes
   a. If everything looks good, one of them will approve it, and your PR will be merged.
   b. The maintainer may request follow-on work (e.g. code fix, linting, etc). We would encourage you to address this work in 2-3 business days to keep the conversation going and to get your contribution in sooner.
   c. Cases exist where a PR is neither aligned to Chef InSpec's product roadmap, or something the team can own or maintain long-term. In these cases, the maintainer will provide justification and close out the PR.

Thank you for contributing!