FWIW, the tests aren't restricted to the datacenter - as they don't involve needing to browse the new domain. All that's being checked here is the returned URL - which since it's being processed (via proxy) on the new deployment, uses the new domain.
We now have a domain and are updating staging to use dashboard.staging.snapcraft.io, but you'll still have the issue that you're hitting myapps.developer.staging.ubuntu.com here, but the response is being served by dashboard.staging.snapcraft.io - as will the returned URL - which is correct.
At a later date, we can update these tests to run against dashboard.staging.., but right now I think they should continue to run against myapps.developer.staging and expect the api response to direct people to the new url.
FWIW, the tests aren't restricted to the datacenter - as they don't involve needing to browse the new domain. All that's being checked here is the returned URL - which since it's being processed (via proxy) on the new deployment, uses the new domain.
We now have a domain and are updating staging to use dashboard. staging. snapcraft. io, but you'll still have the issue that you're hitting myapps. developer. staging. ubuntu. com here, but the response is being served by dashboard. staging. snapcraft. io - as will the returned URL - which is correct.
At a later date, we can update these tests to run against dashboard. staging. ., but right now I think they should continue to run against myapps. developer. staging and expect the api response to direct people to the new url.