fix: change codespaces forwarding domain name to app.github.dev

[mandrasch]

The Issue

Codespaces changed their port forwarding domain from preview.app.github.dev to app.github.dev

To prepare for this change, replace any hardcoded references to preview.app.github.dev in your code with the GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN environment variable by July 31 to avoid any disruptions. The environment variable value will be updated from preview.app.github.dev to app.github.dev when the migration completes. Learn more about environments variables here.

https://github.blog/changelog/2023-07-14-codespaces-port-forwarding-domain-name-updates/

• ddev launch did not work anymore

How This PR Solves The Issue

• replacing preview.app.github.dev with app.github.dev

Manual Testing Instructions

• test ddev launch in codespaces / check with ddev describe if correct domain is used for ddev project url

Info from @rfay: "testing might be as easy as downloading the artifacts from the PR page and running them on Codespaces."

I haven't done this yet - not quite sure how to exactly do this.
(Demo repo I used recently: https://github.com/mandrasch/ddev-craftcms-vite)

Automated Testing Overview

• no automated tests are needed?

Related Issue Link(s)

#5256

Release/Deployment Notes

• none -

[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

[mandrasch]

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

How can I use these for testing? As far as I understand ddev is installed in devcontainer.json? 🤔

{
  "image": "mcr.microsoft.com/devcontainers/universal:2",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/ddev/ddev/install-ddev:latest": {}
},

[rfay]

Just download the linux/amd64 binary and put it in your codespaces environment in the $PATH. Make sure you have the right one, using ddev --version. Then do things. It doesn't matter that it wasn't installed via the devcontainer.json.

[rfay]

Do you know if there's anything like an environment variable or command we can use in Codespaces to get the official app.github.dev ? I hate to wire the wrong thing in again.

Thanks for taking care of this, and for watching out for DDEV Codespaces usage! We don't have an easy way to do automated testing of the Codespaces environment.

[mandrasch]

Do you know if there's anything like an environment variable or command we can use in Codespaces to get the official app.github.dev ? I hate to wire the wrong thing in again.

Yes, there is GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN according to https://docs.github.com/en/codespaces/developing-in-codespaces/default-environment-variables-for-your-codespace.

I'll try to change it and test it the way you described in the next days.

[rfay]

Yes, there is GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN according to https://docs.github.com/en/codespaces/developing-in-codespaces/default-environment-variables-for-your-codespace.

Sorry, I guess you had said earlier about GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN, but didn't use it in your patch.

BTW, you can just open up DDEV with codespaces and switch to the appropriate branch and make. ddev will already be in your path with the built version.

You can then experiment with

previewDomain := os.GetEnv("GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN")

and then use previewDomain in the sprintf that's currently there with a wired domain.

Thanks so much for taking this on and exploring this territory!

[mandrasch]

Thanks @rfay!

Maybe I'll have time to test this tomorrow, but maybe it will be end of week / weekend. (Just as information if anybody wants to fix / try this in meantime since it's a tiny bug. 🤓) Cheers!

[mandrasch]

Just download the linux/amd64 binary and put it in your codespaces environment in the $PATH. Make sure you have the right one, using ddev --version. Then do things. It doesn't matter that it wasn't installed via the devcontainer.json.

Uploaded linux/amd64 ddev file to my project workspace folder and moved it to $PATH location:

chmod +x ddev && sudo mv ddev /usr/local/bin/ddev

(same as in https://ddev.readthedocs.io/en/latest/developers/building-contributing/#testing-a-pr)

Worked, ddev -v gave:

@mandrasch ➜ /workspaces/ddev-craftcms-vite (main) $ chmod +x ddev && sudo mv ddev /usr/local/bin/ddev
@mandrasch ➜ /workspaces/ddev-craftcms-vite (main) $ ddev -v
ddev version v1.22.1-5-gbb588fb88

• ddev launch now works as expected
• Need to replace the domain name with dynamic value as last task

[mandrasch]

ddev launch worked with domain set via env on codespaces, good to go from my point of view! :-)

(Used the new artifact from "PR Build / Build DDEV executables (pull_request)")

[rfay]

I manually tested and it's great, thanks!