-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Low-Code CDK] Write the component schema and use it during manifest validation #20422
[Low-Code CDK] Write the component schema and use it during manifest validation #20422
Conversation
- ApiKeyAuthenticator - BasicHttpAuthenticator - BearerAuthenticator - DeclarativeOauth2Authenticator - NoAuth
…on 'type' not being defined)
…rm validation against the handwritten schema
/publish-cdk dry-run=true
|
…included when package is published
/approve-and-merge reason="This version of the airbyte-cdk has already been released (w/ a patch fix also done this morning) so merging this is a formality more than a release" |
@octavia-approvington @brianjlai I started getting issues in my local low code development workflow after this push. Running https://pypi.org/project/airbyte-cdk/0.16.1/ currently.
This is output from
But as soon as i remove the
Could you help me out here, or should I submit this as an issue? |
hey @franzwilhelm thanks for pointing this out! This is an issue on our end and I see what the problem is. I'll start working on a fix for this |
Workaround for now was to pin the airbyte cdk to
|
hey @franzwilhelm I just pushed an update. Can you try |
Closes #19759
What
Together Catherine, Maxime, and I handwrote json schema that documents all the available components in the low-code language and their respective relationships. This handwritten schema will then be used as the source of truth for the Pydantic models generated, a reference document for low-code developers, and hopefully the UI.
It is also incorporated into the manifest validation flow.
How
A majority of the work was writing the schema by hand. We went through this checklist to avoid duplicates and ensure that we had consistent formatting and styling for the YAML.
The other aspect was incorporating this into the validation flow. We read in the new schema YAML file and perform the same validator check against the incoming schema. The one nuance here is that because we want to deprecate the factory once we have finished the refactor, the new validation flow doesn't use any part of the existing
factory.py
to modify the incoming manifest. That means that we're not doing some of the behind the scenes preprocessing in order to adhere to the component schema.This is handled in the form of the
manifest_component_transformer.py
, which adds certain fields to components so that it can be validate against our ideal schema:type
and have a defined default value$options
dictionary to all subcomponentsRecommended reading order
low_code_component_schema.yaml
manifest_component_transformer.py
manifest_declarative_source.py