Add a function for generating a file to be used for starting the engine and then for hot-reloading. In other words, this function creates a valid string using arguments to replace portions of the string that it generates to represent the config file, it then writes that string as a file to the current working directory. If this file is what we use to start the engine, calling this function again will overwrite that file and initiate a hot-reload. We use this function then to overwrite the file with new runtime values and hot-reload, demonstrating that hot-reload will work for the runtime section.
Once the hot-reload has happened we can validate that the engine is able to correctly process requests.
How was this tested?
Tests create a valid config file, start the engine with that file, assert that requests function correctly, modify that file by saving a new one with the same path triggering a hot-reload, run new requests and assert that they function correctly.
Specifically we test that new paths still result in valid results. And that changing the value of enabled from true to false results in the response changing from status OK to status NotFound.
Sample Request(s)
Example REST and/or GraphQL request to demonstrate modifications
Why make this change?
Adds support for End to End tests within the ConfigurationTests class, along with tests for hot-reloading the runtime section of the config.
Closes https://github.com/Azure/data-api-builder/issues/2438 Closes #2109
What is this change?
Add a function for generating a file to be used for starting the engine and then for hot-reloading. In other words, this function creates a valid string using arguments to replace portions of the string that it generates to represent the config file, it then writes that string as a file to the current working directory. If this file is what we use to start the engine, calling this function again will overwrite that file and initiate a hot-reload. We use this function then to overwrite the file with new runtime values and hot-reload, demonstrating that hot-reload will work for the runtime section.
Once the hot-reload has happened we can validate that the engine is able to correctly process requests.
How was this tested?
Tests create a valid config file, start the engine with that file, assert that requests function correctly, modify that file by saving a new one with the same path triggering a hot-reload, run new requests and assert that they function correctly.
Specifically we test that new paths still result in valid results. And that changing the value of enabled from true to false results in the response changing from status OK to status NotFound.
Sample Request(s)