Several of the packages being installed were actually transitional packages, that is, the package itself is either a complete no-op (since the package is already installed), or else the package only exists to depend on another package of a new name (to support people who are running older operating systems).
For the former, we can drop the dependency entirely, and for the latter we should use the new package name directly.
Through some random machinations, software-properties-common now has a dependency on systemd. This breaks the built docker image as plugins will think systemd is available, so `dokku plugin:install --core` will reference that over sv.
Since we don't manage ppas in Dokku anymore - the only use was for an nginx ppa so we could use a newer Nginx - this can be safely removed.
Also remove some other stuff related to systemd that aren't required anymore.
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
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.
This will allow us to more quickly update a dependency by adding support so that downstream repos can auto-push updates to the main repo when there is a release.
With the integration branch where pull requests are merged prior to a release, we require a rebase every so often to ensure there aren't any issues upon merging to master. Unfortunately, this breaks the link between the original PR and the integration PR, thus causing changelog generation to fail as it depended upon those - now removed - merge request commits.
With this change, we introduce usage of milestones in order to track what is getting merged into a release. Milestones are only used for major/minor releases, and all others will fall back to the default git log method.
This change converts existing CHECKS files into a healthchecks key that is understood by 'docker-container-healthchecker'. This tool supports a number of different types of container healthchecks - command, http, uptime - and can perform healthchecks against non-web processes.
The use of the old CHECKS file is now deprecated, and will be removed in the next minor version. Users can use the 'docker-container-healthchecker' to convert existing CHECKS files to the new format automatically.
Closes#2760
The shorthand is more prevalent in this codebase, and is something that bash supports, so we should just use the same thing everywhere.
Note that we do not use shorthand redirect in Makefile as shell parsing is a bit different in Make and the shorthand redirect doesn't seem to be properly supported, causing CI errors.
This makes standard use of shellcheck work without needing to provide extra configuration anywhere.
Also remove use of inline 'shellcheck disable' calls that are already defined in the .shellcheckrc and don't need to be set inline.
Previously, we would build the dokku package and install it in the same step. While the package building was relatively quick, because of our multi-architecture support, we would end up spending a large amount of time waiting for arm/arm64 images to build.
This change splits those builds out, allowing unit tests to start much quicker and each platform to be tested in parallel.
This change allows us to have an integration branch for each release that contains tested changes for each minor. Rather than have to block merging until a minor is ready for release - and subsequently have to deal with constant rebase issues - we will now have an integration branch per-release. This will be the target for minor-related changes - mostly new features, but also refactors and bc-breaks - while the trunk branch will stay safe for merging patch changes.
Note that we'll still need to rebase the integration branch every so often, but at least this allows us to avoid many long-running MRs.
