Presently, we contribute a process type /cnb/process/health-check for convenience so it's easy to run the health check.
Current Behavior
When using the process type to run the health check this has the side effect of running exec.d helpers, because it runs the launcher. The initial thought was that this would be very fast and not a problem, but it seems like this isn't always true, see #87.
It is also possible that this could trigger unwanted behavior, because any buildpack can contribute an exec.d helper so a custom buildpack could contribute one that is only intended to run once, yet this could cause it to be run many times.
Possible Solution
Remove the process type.
Write a symlink from the health check binary to /workspace/health-check. This will make it easy to invoke but it won't go through the launcher. If something exists at this path, print a warning and don't create the symlink.
When the buildpack runs always print instructions for enabling and running the health check process, including paths, so it's easy for a user to set this up.
Expected Behavior
Presently, we contribute a process type
/cnb/process/health-checkfor convenience so it's easy to run the health check.Current Behavior
When using the process type to run the health check this has the side effect of running exec.d helpers, because it runs the launcher. The initial thought was that this would be very fast and not a problem, but it seems like this isn't always true, see #87.
It is also possible that this could trigger unwanted behavior, because any buildpack can contribute an exec.d helper so a custom buildpack could contribute one that is only intended to run once, yet this could cause it to be run many times.
Possible Solution
/workspace/health-check. This will make it easy to invoke but it won't go through the launcher. If something exists at this path, print a warning and don't create the symlink.Steps to Reproduce
See #87
Motivations
See #87