We use mkdocs to create a static web site that is deployed via Docker images.
We build the static HTML files with mkdocs, then put them in a Docker image that includes an Apache web server.
And then we (our customer actually) deploy the Docker image 8 times, each to a different domain, even with different sub URLs (like e.g. https://domain1/path/one and https://domain2/longer/different/path/two)
With mkdocs 1.2, mkdocs complains that site_url is now mandatory.
How can we solve our use case with mkdocs 1.2?
Is setting site_url to an empty string the recommended way? I think I've read in some tickets ("somewhere"), that setting site_url to an empty string has some negative side effects.
I personally don't think that making site_url mandatory is the right way. In today's containerized world, you often don't know the final domain/URL that your container will be deployed to. And rebuilding a static site for each container deployment is not something that can be done by the image creators.
We use mkdocs to create a static web site that is deployed via Docker images.
We build the static HTML files with mkdocs, then put them in a Docker image that includes an Apache web server.
And then we (our customer actually) deploy the Docker image 8 times, each to a different domain, even with different sub URLs (like e.g. https://domain1/path/one and https://domain2/longer/different/path/two)
With mkdocs 1.2, mkdocs complains that site_url is now mandatory.
How can we solve our use case with mkdocs 1.2?
Is setting site_url to an empty string the recommended way? I think I've read in some tickets ("somewhere"), that setting site_url to an empty string has some negative side effects.
I personally don't think that making site_url mandatory is the right way. In today's containerized world, you often don't know the final domain/URL that your container will be deployed to. And rebuilding a static site for each container deployment is not something that can be done by the image creators.