feat: output the VIRTUAL_HOST if specified in environment variables of a service

[kevinquillen]

The Issue

Right now, ddev describe outputs most of the information one needs to access the various services in a DDEV project. There are cases however where it neglects to output custom VIRTUAL_HOST values from environment sections of a Docker Compose service. These values can allow for vanity domains of a service. This could/would be common with add-on services like Solr, NodeJS applications or similar.

How This PR Solves The Issue

This PR modifies describe.go to try and pull in the information of the environment section of a service.

Manual Testing Instructions

• Build binary of this PR.
• Have a test DDEV project that has a service and set its VIRTUAL_HOST environment variable to "VIRTUAL_HOST=site1.$DDEV_HOSTNAME"
• Start the project with the test binary.
• Run the describe command.
• The output should contain your custom virtual host like the below example.

Before:

Note the NodeJS and Solr services.

After:

Note that the NodeJS and Solr services now show their correct VIRTUAL_HOST values.

These services are now available in the browser at those hostnames. Otherwise, it can appear to be unclear that this is possible to end users. There are cases where users may prefer to access services at custom hostnames instead of default + port and this will add the output to ddev describe.

I could not figure out however how to prepend http:// or https:// to these values.

Automated Testing Overview

These changes do not modify the structure of the describe output, therefore the current TestCmdDescribe needs no change.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

[kevinquillen]

I actually see a better place for this - will update the PR.

[kevinquillen]

I've moved the logic to ddevapp.go instead, which is where it seems that most of this information is assembled to DDEV app-wide.

Now I correctly get http/https URL output if VIRTUAL_HOST is defined along with the mapped ports or their default (80/443).

The 4 added services are 3 NodeJS apps with their own docker-compose file, and Solr. The first nextjssite1 uses the default hostname, with port 9999 mapped, demonstrating that the current functionality works with the new changes.

I noticed that the map order is not guaranteed, so I resorted to storing these 3 env values into a map so I could ensure I had them. Otherwise, sometimes you get HTTP_EXPOSE or HTTPS_EXPOSE as the first env in the loop, then VIRTUAL_HOST, or vice versa, resulting in inconsistent and erroneous values. This appears good to me, but I am new to Go so its possible that the logic could be more compact than this.

[kevinquillen]

Buildkite apparently failed for testnotddevapp - is there a way to quickly check that locally?

[rfay]

Buildkite apparently failed for testnotddevapp - is there a way to quickly check that locally

It's likely a transient failure. If you PM me your email I'll give you privileges on buildkite and you can restart tests.

[kevinquillen]

Yes, appears that it was just a transient failure.

[rfay]

Rebased, mostly just to run a new test runner.

[stasadev]

Tested, ddev describe looks good, I just have a small suggestion.

[kevinquillen]

Yeah that makes sense, accepted the change.

[stasadev]

Thank you!

[rfay]

I'm sorry we didn't get this into v1.23.1, we were trying to make it as minimally disruptive as possible. It should get into v1.23.2.

[rfay]

Rebased.

[rfay]

Thanks, looks great to me. Manually tested in a number of situations.

Maybe a followup docs PR explaining how to use VIRTUAL_HOST as used here would be a good thing.

I used a .ddev/docker-compose.solr_extra.yaml with

services:
  solr:
    environment:
      - VIRTUAL_HOST=mysolr.${DDEV_HOSTNAME}

And a config.solr.yaml with:

additional_hostnames: [mysolr.d10]

[kevinquillen]

@rfay The docs sort of allude to it when I was looking for an applicable place. I made a small edit that shows a subdomain approach.

#6229