We need to decide where it should be “built” and where it should be published to.
docs.renovatebot.com is a good possibility
Should the build script be in the main Renovate repo or the docs one? If it’s in Renovate then we could generate the schema and then validate it as part of tests to make sure we never “break” it. Then the docs build script will execute it also and save the result to the web.
I would prefer it to build on docs. But we can use a simple jest snapshot test to validate on renovate repo.
So only the snapshot can be conflicted, but can easily updated.
we also see the snapshot diff on errors and on pr
I’m aiming that people authoring need managers only need to update lib/manager/x though
Ok, maybe we can do a manual schema check, which makes sure we do not loose something. So only adding properties / objects is allowed.
I can do this with some magic jest Foo. 🤪
Could we publish to JSON Schema store? And include the (non-standard) $schema property in the onboarding renovate.json?
Can the publishing be automated?
Nice idea, we can add there a link to our schema. It must not live in their repo.
https://github.com/SchemaStore/schemastore/blob/master/src/api/json/catalog.json
See angular schema as example
Yes but then shouldn’t the URL be on docs.renovatebot.com in future? Either that or a dedicated repo that we push to with Actions
Another alternative:
Could be conflict if a master build is running and we merge another pr
I think such a race condition should be extremely rare and also immediately recoverable because the second PR merging would result in a new action running and committing the right JSON schema (if updated).
:tada: This issue has been resolved in version 19.129.1 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Most helpful comment
Here it is: https://docs.renovatebot.com/renovate-schema.json