Drop hardcoded /application path

[kdambekalns]

The handling of .warmupdone & beach-cron-hourly.sh used an hardcoded path instead of whatever BEACH_APPLICATION_PATH was set to.

[kdambekalns]

Hm… This probably needs an adjustments to whereever .warmupdone is actually used (health check, …) – or we leave that as is?

[robertlemke]

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:

https://github.com/flownative/beach-controlpanel/blob/dfe8544657c49605dae9d3f71aa9e8502072f040/DistributionPackages/Flownative.Beach/Classes/Domain/Context/Instance/Service/InstanceKubernetesService.php#L1069

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.

[kdambekalns]

A chicken-out solution would be to leave the .warmupdone where it currently is – no harm done. I'll think about it…