Fixes #2177 Providing own definition file to Docker container via SWAGGER_FILE

[eugene-khyst]

Motivation and Context

Fix providing own json or yaml definition file to Docker container via SWAGGER_FILE env variable.
Fixes #2177

How Has This Been Tested?

Build the Docker image

docker build -t swaggerapi/swagger-editor .

Run the Docker container without providin own json or yaml specification file

docker run --rm -p 8080:8080 swaggerapi/swagger-editor

Open http://localhost:8080 to verify that the default Pet Store Swagger specification(https://petstore.swagger.io/v2/swagger.json) is loaded.

Download custom OpenAPI 3.0 specificcation file to specs directory

mkdir specs
curl https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml --output specs/petstore.yaml

Run the Docker container, mounting specs directory and pointing SWAGGER_FILE to /specs/petstore.yaml

docker run --rm -p 8080:8080 -v $(pwd)/specs:/specs -e SWAGGER_FILE=/specs/petstore.yaml swaggerapi/swagger-editor

Open http://localhost:8080 to verify that the custom Pet Store OpenAPI 3.0 specification (/petstore.yaml) is loaded.

In the source code of the index.html make sure url: '/petstore.yaml' is present:

const editor = SwaggerEditorBundle({
    url: '/petstore.yaml',
    dom_id: '#swagger-editor',
    layout: 'StandaloneLayout',
    presets: [
        SwaggerEditorStandalonePreset
    ]
})

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[tim-lai]

@evgeniy-khist Merged! Thanks for the contribution!