The test uses hashable, however it is not regularly updated to support
the latest haskell GHC versions. primitive is better for this purpose and
does support the just released haskell GHC 9.4
This test validates that the Python images do not contain any pre-compiled `.pyc` or `.pyo` files in `/usr/local` (or `/opt`, for good measure).
Ideally this would also include all of `/usr` (not just `/usr/local`) but then it would also have to filter out results that are from Debian packages (`python`'s default variants are `FROM buildpack-deps` which includes a fair amount of Python packages).
This was broken in the new Elasticsearch 8.0, but while looking at how to fix it (disabling auth, for starters) I realized it wasn't really providing any real value anymore, so instead of trying to adapt it to the updated API requirements of 8.0, I chose to remove it instead.
This adjusts `nextcloud-apache-run` and `nextcloud-fpm-run` to try up to three times for a successful result, and adds a new `nextcloud-cli` test that combines the other three (`nextcloud-cli-mysql`, `nextcloud-cli-postgres`, and `nextcloud-cli-sqlite`) into a single test that will pass if any one of them passes (but does attempt to run all three every time).
Also, account for change in the installation page (from "Finish setup" to "Install").
Haskell stack can be slow to add new Haskell compiler versions.
The stack container test will fail until this is done, which blocks
docker Haskell updating as well.
Rather, lets ignore that particular failure, but still verify
with stack if the compiler version is supported.
This is a follow-up of #9914. The now current approach works well EXCEPT
when people exec into the container with `bash` or whatever since the
entrypoint can't work it magic.
So, the blunt approach is to create a series of trampoline scripts that
will just add `-n /var/lib/varnish` before all arguments. It's not super
elegant, and I'm not a fan of overloading `PATH` but:
- it works transparently
- you can easily bypass the trampoline by using the binary's absolute
path
I decided against generating the scripts from the `Dockerfile`s to avoid
escape hell, but I can be convinced otherwise if it makes reviews
easier.