Closed m-s- closed 11 months ago
We are exploring if this can be fixed in the DF side or if we need to add a (temporary) feature to the CLI to support both scenarios. However, this will break one of the principles of the packages, being agnostic to installation target.
A work around would be to edit the generated package and replacing the tokens with ones supported by the traditional installation process:
$(TENANT_NAME) -> $(Product.Tenant.Name)
$(APPLICATION_PUBLIC_HTTP_TLS_ENABLED) -> $(Product.ApplicationServer.EnableSsl)
$(APPLICATION_PUBLIC_HTTP_ADDRESS) -> $(Product.ApplicationServer.Address)
$(APPLICATION_PUBLIC_HTTP_PORT) -> $(Product.ApplicationServer.Port)
$(SYSTEM_NAME) -> $(Product.SystemName)
"$(SECURITY_PORTAL_STRATEGY_LOCAL_AD_DEFAULT_DOMAIN) -> $(Product.Security.Domain)
replace $(APPLICATION_BASE_HREF)
with /
This is technically a Deployment Framework bug, not a CLI bug, but I've tagged the issue as such anyway for easier reference.
Thanks for your guidance, my page can also be displayed, otherwise I will be stuck in the project
This is fixed by MES 10.1, in which VM DF understands the container tokens
CLI will place environment specific tokens in config.json, index.html and ngsw.json that should be replaced by DF when installing the package. However, the tokens supported by the container entrypoints and the traditional DF installation are not compatible, causing the package to install with tagging in VMs and the UIs to not work anymore.