-
Notifications
You must be signed in to change notification settings - Fork 45
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
Review of reported errors from local run CAMARA linter to confirm conformance with API Design Guidelines for Traffic_Influence.yaml #191
Comments
I'm not sure on how to retrieve the error on the YAML. First, which version of the TI API YAML was used? Then, let's use this as an example: "124:7 error oas3-valid-schema-example "example" property must match format "ipv4" " What does 124:7 means? I supposed that 124 was the line in the YAML, but I couldn't find a match. |
About: "125:23" URLs are already in Kebab-case /traffic-influences |
Hi Fabrizio, apparently draft version had a bug checking Kebab-case in path. Links for linter files from commonalities (referenced in in #170) are working now (updated in main branch). We have rerun it with current Traffic_Influence.yaml ( the one in progress in #167 And current output is the following:
|
Just 3 errors:
The rest are just warnings or hints. BTW: I agree that some times is confusing/not accurate the line:column number on the output. |
About error 200:16. According to my understanding, the tool doesn't recognize some methods as GET, PATCH and DELETE. Even if they actually are GET, PATCH and DELETE. I suppose the reason is that we defined "parameters" as child of "paths" rather than child of the "methods". Is this a prescription from the CAMARA Guidelines? Because our implementation is correct according to the OpenAPI Specifications (https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#path-item-object). We have used the "parameters" description as child of "path". With our solution we avoid duplicating the parameter definition for the different methods (Get, Patch and Delete). With the suggested approach we should define the same parameter three times in the code with the risk of code misalignment. |
many warning are not correct. For example 408:15. The warning states that we have not described the property "state" in "PatchTrafficInfluence". Actually, we used the keyword "allOff" importing all the properties from "/components/schemas/TrafficInfluence" where the property "state" is described. Actually, if you see the code in swagger, the property "state" in "PatchTrafficInfluence" is correctly described. |
- alignement of parameters with EdgeCloud_LCM: applicationId changed into appId and instanceId changed into appInstanceId - modified reference to CAMARA Authorization guidelines link - Telco Edge Site changed in Edge Cloud Zone (camaraproject#163) (camaraproject#191) - added: info-contact - Device: IPV4 and IPV6 changed to represent just one IP. Net mask is no more valid. - global tags definition - adopted lowerCamelCase for OperationId - added descriptions for Delte and Get (for specific resource) methods - added missing operationid - improvement of callback definition - added "description" to the TrafficInfluence resource - added "description" to the PatchTrafficInfluence resource - added "description" to TrafficInfluenceNotification - added "description" to NetworkAccessIdentifier - added "description" to ErrResponse - added "description" to message - added "description" to status - added "description" to ErrorInfo - removed unused error code SessionNotFound404
- alignement of parameters with EdgeCloud_LCM: applicationId changed into appId and instanceId changed into appInstanceId - modified reference to CAMARA Authorization guidelines link - Telco Edge Site changed in Edge Cloud Zone (camaraproject#163) (camaraproject#191) - added: info-contact - Device: IPV4 and IPV6 changed to represent just one IP. Net mask is no more valid. - global tags definition - adopted lowerCamelCase for OperationId - added descriptions for Delte and Get (for specific resource) methods - added missing operationid - improvement of callback definition - added "description" to the TrafficInfluence resource - added "description" to the PatchTrafficInfluence resource - added "description" to TrafficInfluenceNotification - added "description" to NetworkAccessIdentifier - added "description" to ErrResponse - added "description" to message - added "description" to status - added "description" to ErrorInfo - removed unused error code SessionNotFound404
Linting rules (spectral) have been updated to be compatible with TI API methods definition. https://github.com/camaraproject/Commonalities/pull/169/files @sergiofranciscoortiz is the new spectral.yaml automatically used by Edge Cloud MegaLinter or do we need to update it? |
@FabrizioMoggio I'm not sure if MegaLinter uses the new spectral.yaml but since passing the Linter test is mandatory, you could ask at commonalities if passing MegaLinter is enough to cover it or we need to use spectral.yaml locally. P.S. Sergio is no longer part of the project, I'm covering for him in case you need anything or if I miss any important information regarding EdgeCloud Apis.😄 |
I include @rartych in the loop to ask him how to move forward considering camaraproject/Commonalities#169. Rafal, how do we update Edge Cloud MegaLinter to include that PR? |
You need just to update the https://github.com/camaraproject/EdgeCloud/blob/main/.spectral.yml (replace it with the new version from: https://github.com/camaraproject/Commonalities/blob/main/artifacts/linting_rules/.spectral.yml ) |
@javierlozallu I will wait for the spectral update to update the TI PR (#167) with a new YAML that fixes the all the MegaLinter errors. Please let me know here when it is done. |
Meanwhile, @gunjald as mentioned in the meeting, could you ask Commonalities for a tool to test common parameters across APIs and also, as you mentioned, if we can configure MegaLinter to test a specific set of YAMLs instead of the whole repository? Please update us here or create a new discussion if you think it is better to have it separate. |
MegaLinter has rather static configuration with the filters for files included/excluded for the linting. I guess you would like to lint files for given API depending on the content of PR. |
Hi @FabrizioMoggio, I have created PR #231 to update spectral.yaml with the latest version. Please check it to merge. |
After running locally CAMARA linter scripts indicated in #170, although using draft spectral , along with files in lint_function_folder, following errors/warnings appear:
To be double checked if correction is needed in yaml to avoid those errors/warnings ( at least the kebab case one seems a false positive). Most of them are warnings for missing parameter descriptions.
The text was updated successfully, but these errors were encountered: