The loader script located at (https://forge.etsi.org/swagger/tools/loader.html) was unable to properly derive the branch name for a non-master branch from the HTTP referrer. As a workaround, we had to hard code the branch and repo names as the script parameter values (in the link). The problem with this approach is that when temporary branch is merged into master, the file with links to the https://forge.etsi.org/swagger/tools/loader.html has to be edited and the branch name changed there into master. There were also problems with forming the proper URL to be passed to the swagger editor - the script assumes that the *.yaml files are in the root of the repo. We came across this problem while working in https://forge.etsi.org/rep/3GPP/SA5/data-models/tree/master/OpenAPI See what had to be hardcoded in the README.md... The "fun" begins when CR creators will be creating new branches - the README.md in the new branch will be pointing at he master branch (they will not see new/modified YAML files by following the links).
Hi Anatoly, I totally agree that hard-coding branch names in the README is not correct, as it will break the links for any subsequent commit. The Loader.html was tightly coupled to the 5G_APIs project, therefore I uploaded a new version which supports any project in the Forge Gitlab installation. Regarding the 'yaml=' parameter, it is expected that if the yaml is in a subfolder the subfolder shall be indicated in the parameter (as you already did). I tested it with success with the links available in this revision: https://forge.etsi.org/rep/3GPP/SA5/data-models/tree/0a9408466f8d6ce699958d2aaa801cfc92ed6be0/OpenAPI Please confirm that it works at your end as well, thank you for reporting the issue! If the issue is correct, please fix the URLs in the README.md file.
Hi Michele, I've tested the new loader script (see the "testing_loader.html_script" branch). It mostly works (the original problem described in this bug report is fixed). But there is a second issue (with the swagger editor hosted by ETSI Forge): - if you go to OpenAPI directory of SA5 repository and click on any of the "Editor" links, the loader.html is invoked with the right options and then the swagger editor is loaded properly (hint - this happens only when you do it "first" time) - if you back-out from the swagger editor (hit the "back" in your browser) and then click on any _other_ "Editor" link, then the swagger editor opens... BUT!!! it shows "wrong" YAML file (e.g. if in the previous step you tried to display genericNrm.yaml, and in this step you selected nrNrm.yaml, the same genericNrm.yaml will be displayed). - this problem is 100% repeatable. - there are couple of workarounds: - "advanced" (not good for a regular user, but 100% reliable) - you have to delete the cookie stored by swagger editor in your browser... then the next load is "good" - "simple" (may be acceptable for a regular user, but not 100% reliable and potentially confusing) - you have to "clear editor" under swagger editor's "file" menu and then reload the page. The fix is unreliable as sometimes you may end-up with the default "petstore" API definition. Google search returns multiple hits describing this swagger mis-behavior. The common knowledge seems to point at the server set headers (like Expires or Cache-Control) - see https://github.com/swagger-api/swagger-editor/issues/1412 as an example. Thank you! Regards, Anatoly
Hi Anatoly, Indeed it seems a bug of the Swagger Editor itself. See also: https://github.com/swagger-api/swagger-editor/issues/209 I installed version 3.8.0 of the editor https://forge.etsi.org/swagger/editor-versions/v3.8.0 and the error is produced as well. The webserver does not set Expires or Content-Cache headers, so it is hard to investiate in that direction. I am afraid for the moment being the solution if to keep hard refreshing the page (Ctrl+F5) or clearing the editor from the menu, as you suggest. I will come back with updates asap.
