3GPP Forge FAQ

5G API Project

1. Which tools are used t

The cross files reference works fine in my local tool, I suppose same to Anatoly, but seems still have problem on swagger editor/UI in Forge. The external yaml file couldn’t be recognized by Forge integrated swagger editor or UI tool and there’s error reported. (Do you face the problem before? (Note: seems all CT yaml files are self-contained, it didn’t refer to external yaml file).

2. How are the 5G_API yaml files validated?

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?

 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.

SA5 Data Models Projects

- who has write access to SA5 project repository? -à all SA5 delegates

 - 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