Open kdambekalns opened 1 month ago
Hm… This probably needs an adjustments to whereever .warmupdone
is actually used (health check, …) – or we leave that as is?
You can make the path leading to .warmupdone
configurable as you did, if you also make the configuration of the health check for instance pods more flexible. Problem is that if you configure the APPLICATION_PATH variable as an instance variable, there's no easy way to access it in the code which generates the pod configuration:
We could make the application path a "first-class-citizen", or more specifically, a property of an instance. Currently there's a concept called "DeploymentFlags" used for that, you might want to check the respective model. There's also the concept of userProvidedConfiguration
in those flags, but it is not very elaborate.
In the end, we need to decide if we want to take the extra step and create a way to configure those kinds of variables / properties in a general fashion via the UI or .beach.yaml. Or if we find a workaround.
Another approach might be to make the health check endpoints configurable.
A chicken-out solution would be to leave the .warmupdone
where it currently is – no harm done. I'll think about it…
The handling of
.warmupdone
&beach-cron-hourly.sh
used an hardcoded path instead of whateverBEACH_APPLICATION_PATH
was set to.