-
Notifications
You must be signed in to change notification settings - Fork 18
feat: Implement the extensions RFC 0002 #167
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
feat: Implement the extensions RFC 0002 #167
Conversation
Signed-off-by: Mark Wiebe <[email protected]>
Signed-off-by: Mark Wiebe <[email protected]>
093ce61 to
797fc8b
Compare
Signed-off-by: Mark Wiebe <[email protected]>
b5c74c5 to
03ccc01
Compare
|
| if schema_version == TemplateSpecificationVersion.JOBTEMPLATE_v2023_09: | ||
| return parse_model(model=JobTemplate_2023_09, obj=template) | ||
| return parse_model( | ||
| model=JobTemplate_2023_09, obj=template, supported_extensions=supported_extensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question, will we change this in the near future? 2025_03 or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think it's better to accumulate a series of extensions before starting a new revision.
leongdl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM


What was the problem/requirement? (What/Why)
https://github.com/OpenJobDescription/openjd-specifications/blob/mainline/rfcs/0002-model-extensions.md
What was the solution? (How)
Implement support into template parsing.
What is the impact of this change?
RFC 0001 and other later RFCs can be implemented in a manner conformant with RFC 0002. The base 2023-09 specification stays the same, except when a list of names for
extensionsis provided in the template, and the implementation processing the template supports those extensions.How was this change tested?
Yes
Was this change documented?
Yes
Is this a breaking change?
It's not a breaking change. the new parameter
supported_extensionfor parsing a template is optional, and if none are provided, it uses the base specification with no extensions enabled.Does this change impact security?
This does not impact the threat model, and the new extensions field and parameter follow the same level of input validation relevant for existing threats.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.