taskcluster-base: Our deploy process for api references and json schemas should ensure that all references continue to validate against schemas

NEW
Assigned to

Status

Taskcluster
Redeployability
3 years ago
17 days ago

People

(Reporter: pmoore, Assigned: pmoore)

Tracking

(Blocks: 1 bug)

Details

(Assignee)

Description

3 years ago
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.
Flags: needinfo?(pmoore)
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
(Assignee)

Comment 2

3 years ago
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!
Flags: needinfo?(pmoore)
(Assignee)

Updated

3 years ago
Component: TaskCluster → General
Product: Testing → Taskcluster
Component: General → Platform Libraries
Component: Platform Libraries → Platform and Services

Updated

4 months ago
See Also: → bug 1433672
Component: Platform and Services → Redeployability

Updated

23 days ago
Blocks: 1457584

Updated

17 days ago
Assignee: nobody → pmoore
You need to log in before you can comment on or make changes to this bug.