In other words, if we e.g. update a reference, such as: http://references.taskcluster.net/queue/v1/api.json then our deployment process should automatically validate that it conforms to: http://schemas.taskcluster.net/base/v1/api-reference.json i.e. not allow a reference to be deployed that does not validate against its schema. Likewise we should probably ensure that if a schema is updated, that all existing references that validate against it, can still validate successfully. This can be slightly trickier, to know which references are pointing to any given schema... However maybe that can be solved if we bump/hash the version number, so we never replace an old schema (I believe currently we reuse "v1"). Currently http://references.taskcluster.net/queue/v1/api.json does not validate against http://schemas.taskcluster.net/base/v1/api-reference.json which I have raised separately in bug 1134264.
This is already done... they validate against the schemas that are in the taskcluster-base repository. I think this is more stable than loading from reference.taskcluster.net in production, which is sketchy for robustness. If this ^ is satisfactory, let's close this... And push new references from taskcluster-base to references.taskcluster.net util to do so is in tc-base, I can do it... (note I added comment about it in another branch). > Likewise we should probably ensure that if a schema is updated, that all existing references that > validate against it, can still validate successfully. Ideally, yes.. In practice... We shouldn't start doing this until we've decided that the reference format is stable. We clearly have outstanding issues with it. Such as the discussion about using swagger and the ability to add querystring parameters to GET requests (at minimum). @pmoore, I think it's best to be practical for now... And not lock things down as declared stable. That's why we have version numbers such as 0 and 0.2.0. Note, I'm open to starting design discussions on getting to a point where we're reasonably confident locking down how references looks. I think part of this is considering swagger/json-hyper-schema vs. our own. Part of it is considering pulse guardian and discussing if exchange references could be a pulse feature. And part of it involves figuring out how docs should be generated on-deploy of components.
Summary: Our deploy process for api references and json schemas should ensure that all references continue to validate against schemas → taskcluster-base: Our deploy process for api references and json schemas should ensure that all references continue to validate against schemas
OK, let's park this then for a later time, agreed. Maybe an auto-deploy after an r+ and merge would be good just to make sure published schemas are consistent with latest versions in vcs, but the other matters we can sketch out when the schema definition framework decisions have been made. Thanks!
Component: TaskCluster → General
Product: Testing → Taskcluster
Component: General → Platform Libraries
Component: Platform Libraries → Platform and Services
Component: Platform and Services → Redeployability
You need to log in before you can comment on or make changes to this bug.