Building/testing for ARM does not happen often - the only runtime environment is Raspberry PI, which supports ARM64 - and complicates support for a ton of features. Aside from that, CI runs are much longer for ARM Dokku images, often reaching 15-20 minutes or just timing out completely.
Rather than support an architecture that doesn't have much usage by maintainers and has a lot of maintenance burden, we're removing the platform.
Exposing all config values will allow users to skip setting environment variables twice - once as a docker option and once as an env var. Docker will automatically pull the value from the environment if none is set for the --build-arg flag.
Users will still be required to specify each desired env var via --build-arg as otherwise docker builds will complain about unused build arguments.
Re-implements #5978 (lost in a rebase)
Closes#5903
Recent Dokku changes invalidate a bunch of docs around where files need to be placed in order for Dokku to respect them. This doc change clarifies where files are extracted from in cases where source code is available, which should hopefully make users less confused about how the system works.
See https://railsnotes.xyz/blog/deploying-ruby-on-rails-with-dokku-redis-sidekiq-arm-docker-hetzner for the inspiration - I was reading through it and was like 'these docs are definitely incorrect...'.
While we will still build for 18.04, we will now stop testing against it. Instead, we will test against 20.04, the next EOL release after 18.04.
Once Ubuntu 18.04 is EOL, any references to it will also be removed.
Note that 18.04 support was already deprecated in Dokku 0.28.0, so this change is just acknowledging that deprecation.
While the majority of buildpacks do not work on non-amd64 platforms, this will at least allow developers the option to choose when to override this setting.
This is useful when there is a service not managed by Dokku but should be exposed via the Dokku routing layer. As an example, some binaries (consul, nomad, vault) expose web uis, and are traditionally run on the host directly vs in a container.
Closes#4665
We should treat the project.toml as an optional file, as is the Procfile. Additionally, moving the file into place early will ensure there is no chance of selecting the wrong file.
