When we create a resource and manually override its FQDN through the interface, the change is properly taken into account in the Traefik labels.
However, this change is not reflected by generateFqdn, which means that our SERVICE_FQDN_ and SERVICE_URL_ special variables do not match the real expected FQDNs.
Minimal Reproduction (if possible, example repository)
Create any resource that uses SERVICE_FQDN_
Update the resource FQDN through the interface
Notice the Traefik labels are properly updated with the new FQDN
Notice the SERVICE_FQDN_ auto-generated variable is not updated with the new FQDN
Proposed solution
After looking through the code, I've noticed that the generateFqdn function (Here) could maybe be improved using a third parameter set to $resource->fqdn when $resource->getMorphClass() === 'App\Models\Application'. (Here, for example).
Though I'm not sure how that could be fixed for the case where $resource->getMorphClass() === 'App\Models\Service'.
Description
When we create a resource and manually override its FQDN through the interface, the change is properly taken into account in the Traefik labels.
However, this change is not reflected by
generateFqdn
, which means that ourSERVICE_FQDN_
andSERVICE_URL_
special variables do not match the real expected FQDNs.Minimal Reproduction (if possible, example repository)
SERVICE_FQDN_
SERVICE_FQDN_
auto-generated variable is not updated with the new FQDNProposed solution
After looking through the code, I've noticed that the
generateFqdn
function (Here) could maybe be improved using a third parameter set to$resource->fqdn
when$resource->getMorphClass() === 'App\Models\Application'
. (Here, for example).Though I'm not sure how that could be fixed for the case where
$resource->getMorphClass() === 'App\Models\Service'
.Exception or Error
No response
Version
v4.0.0-beta.319
Cloud?