Use $schema keys for menuinst JSON validation
#5569
Conversation
conda-bot
added
the
cla-signed
|
@conda/builds-tools, this is ready for review! 🙏 See conda/menuinst#283 for broader context. |
|
|
||
|
|
||
| @cache | ||
| def _build_validator(url): |
There was a problem hiding this comment.
Shall we restrict which domains can be provided so they can only come from a series of pre-approved locations? e.g. github.com/conda/menuinst, schemas.conda.org, etc. Otherwise users might be able to simply link the equivalent of "allow-everything" schema and bypass these validations. Not that they result in errors, though.
There was a problem hiding this comment.
There was a problem hiding this comment.
With conda/infrastructure#1082 now closed, I think we should restrict it to that domain.
CodSpeed Performance ReportMerging #5569 will not alter performanceComparing Summary
|
|
Gentle ping, @conda/builds-tools. |
|
Blocked by conda/infrastructure#1082 |
|
|
||
|
|
||
| @cache | ||
| def _build_validator(url): |
There was a problem hiding this comment.
With conda/infrastructure#1082 now closed, I think we should restrict it to that domain.
| r = requests.get(url) | ||
| if not r.ok: | ||
| log.error("Could not fetch '%s', status code %s", r.status_code) |
There was a problem hiding this comment.
This would have to handle requests exceptions better.
| "https://github.com/conda/menuinst/raw/refs/tags/2.2.0/" | ||
| "menuinst/data/menuinst.schema.json" |
There was a problem hiding this comment.
We shouldn't hardcode a GitHub URL that way
Description
Recent changes in menuinst fixed this design issue. We can now safely rely on
$schemato self-validate the JSON document. As a result,menuinstis no longer necessary as a dependency either.Checklist - did you ...
newsdirectory (using the template) for the next release's release notes?