3GPP Forge FAQ

From ETSI Forge
Revision as of 12:30, 30 April 2020 by Carignani (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

5G API Project

How are the 5G_API yaml files validated?

Detailed question

Based on Jenkins and Validation scripts in Forge, I have supposed yaml code would be validated in CI pipeline, e.g. commit, merge, etc. However seems all pipelines recently were passed successfully while I did detect a few minor errors in one OpenAPI yaml file with my local validation tool and swagger editor. I’m not familiar with detail of Jenkins, could you explain what’s the expected result with the validation? E.g. could the change be committed/merged with validation error? Would the error be reported somewhere?

Answer

The scripts used to validate the 5G_API project are openly available at https://forge.etsi.org/rep/forge-tools/3gpp-scripts. In particular, the validation is executed in the file validate-all.sh, using the tools ‘swagger-cli validate’. The result of the validation is reported for each with a green/red badge and is visible at the bottom of the commit page (see this example). Clicking on the badge itself you can navigate to the individual Jenkins jobs with the detailed output (in the example, this one). In the actual configuration of the project, failing builds are still allowed to be merged, the result is just for information to the committer and maintainers.

The swagger editor retains data from previously opened files

SA5 Data Models Projects

Who has write access to SA5 project repository?

All SA5 delegates. Complete member list is available at https://forge.etsi.org/rep/3GPP/SA5/data-models/project_members.

 - what is our preferred mode of operations to add the SA#87 YAML baseline - should I try adding it to the master branch or should I try creating a separate branch with all the changes and then request it to be merged onto master? àseparate branch and request to merge into the master branch

 - what is our preferred mode of operation for individual CRs (on top of the SA approved baseline, assuming that the step described above is completed) - do we create a new branch for each CR (and use individual commits on that branch to track CR/t-doc revisions)? à yes, this sounds to me the way to go.

 - who is responsible for merging the branches of approved CRs (after the SA plenary) into the master release branch? à MCC