Drop the assertion that the web deployment has no command since the python buildpack auto-emits a web Procfile entry, which correctly routes through launcher just like docker-local. Shorten the cron command fixture so the base36-encoded cron-id stays under the 63-byte kubernetes label limit, and relax the `dokku run` and `dokku cron:run` output assertions to `assert_output_contains` so they tolerate the leading blank line emitted on k3s.
The scheduler-run script classified CNB-based images as `herokuish` because
`is_image_herokuish_based` returns true for them, which caused the
`docker-args-process-run` trigger for builder-pack to skip injecting
`--entrypoint launcher`. Without that flag the container fell back to the
image entrypoint (`/cnb/process/web`) and dropped the user-supplied
arguments. Mirror the deploy-side detection so CNB images set
`IMAGE_SOURCE_TYPE=pack`, allowing the launcher entrypoint to be added.
The jq binary doesn't support jsonc, so we can't modify it for testing purposes. Instead, just create an app.json with the correct heroku.postdeploy task.
Users that misconfigure their process's listening interface or port will now see an additional healthcheck warning for web deploys. While only a single port is checked, this ensures that users at least have some context as to why their app isn't responding as expected.
Closes#4798
During an app build, we now auto-detect ports based on the source code. This is usually http:80:5000, with Dockerfile-based deploys having their ports extracted from the docker image or Dockerfile. Additionally, we add an https:443 mapping for any detected http:80 mapping when there is an ssl certificate, and all http port mappings are transformed to https mappings for Dockerfile-based deploys.
While the ports aren't currently consumed, a future refactor will provide the ability to fallback to the new detected ports when there is no user-specified port mapping.
This allows folks to deploy apps that don't have a web process without needing to scale that process down before/after the first deploy. Note that the formations key in the app.json or a manual scale of other processes will be necessary to start anything non-web.
Closes#5700
They are not baked into the image like they are for herokuish, so we need to manually set them via --env. Additionally, due to newline constraints in docker, we need to use `--env=key` format to correctly pull the values into place.
This functionality enables users to manage a global crontab for the Dokku user that contains all scheduled tasks across all apps. Alternative schedulers can implement cron tasks as desired.
