⭐ [Enhancement]: Enhance Command Line & Console Output

[JerryNixon]

What is it?

• Update dab init to create a .env file when a connection string is supplied.
• Update dab start to output a summary table after starting.
• Add dab validate -output: test-result.xml for CICD automation.
• Make progress on dab configure to edit everything from the command line.

Automatic .env file

1. Create the .env file

   • If dab init is passing an @env() value, then do not continue with this.
   • If a .env file already exists, modify it.

2. Use a default environment variable name my-connection-string

Simple .env file contents:

my-connection-string=whatever-the-user-provided

4. Reference the environment variable name in the dab-config.json file.

Using variables in the JSON:

{
  "$schema": "...",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('my-connection-string')"
  }
}

dab start Summary table

Today, it's just console logs. This is not new information, just easier to use.

Http Endpoint	Https Endpoint
OpenAPI	http://localhost/API/OpenAPI	https://localhost/API/OpenAPI
Swagger	http://localhost/swagger	https://localhost/swagger
GraphQL	http://localhost/graphql	https://localhost/graphql
Health	http://localhost/	https://localhost/

When production

Http Endpoint	Https Endpoint
OpenAPI	http://localhost/API/OpenAPI	https://localhost/API/OpenAPI
Swagger	mode=Production	mode=Production
GraphQL	mode=Production	mode=Production
Health	http://localhost/	https://localhost/

When no HTTPS

Http Endpoint	Https Endpoint
OpenAPI	http://localhost/API/OpenAPI	Not Configured
Swagger	http://localhost/swagger	Not Configured
GraphQL	http://localhost/graphql	Not Configured
Health	http://localhost/	Not Configured

dab validate Output File

The flag dab validate -output:results.xml extends dab validate to support outputting the validation results in a machine-readable XML format useful for CI/CD pipelines. This allows for automated validation of configuration files, where any validation errors will be written to the specified XML file for further processing or reporting just like unit test. It's okay to still output to the console.

Sample file

The JUnit XML format is widely used for reporting test results and is supported by most CI/CD tools (Jenkins, GitLab CI, Azure DevOps, etc.). You can find the JUnit XML schema reference and examples at the following link: JUnit XML Format.

<testsuites>
  <testsuite name="DABConfigurationValidation" tests="4" failures="3">

    <!-- Test Case for Missing Connection String -->
    <testcase classname="DataSourceValidation" name="Missing Connection String">
      <failure message="Connection-string is not present in the data-source.">
        The data-source section is missing the required 'connection-string' field.
      </failure>
    </testcase>

    <!-- Test Case for Empty Entities Array -->
    <testcase classname="EntityValidation" name="Entities Array is Empty">
      <failure message="The entities[] array has no entities.">
        The entities array in the configuration is empty. Please define at least one entity.
      </failure>
    </testcase>

    <!-- Test Case for Invalid Runtime Host Mode -->
    <testcase classname="RuntimeHostValidation" name="Invalid Host Mode">
      <failure message="runtime/host/mode has an invalid value.">
        The value 'abc' for runtime/host/mode is invalid. Expected values are 'development', 'production', or 'staging'.
      </failure>
    </testcase>

    <!-- Test Case for Valid Authorization Provider -->
    <testcase classname="AuthorizationProviderValidation" name="Valid Authorization Provider">
      <!-- No failure, this passes -->
    </testcase>

  </testsuite>
</testsuites>

Related issues to potentially close

• 2296

• 2295

• 2251

• 2000

• 1924

• 1861

• 1781

• 1477

• 2276

• 1796

• *2168