Replace the pytest/testinfra/tox test stack with BATS, aligning with
the approach used in the FTL repository.
- Merge build-and-test.yml into build-and-publish.yml; the combined
lint+test job now runs on pull_request via a single bash test/run.sh
call, removing the need for Python/tox in CI
- Replace Python test files with test/run.sh and test/test_suite.bats
- test/run.sh handles image build, BATS install, container lifecycle,
and cleanup via trap in one place
- Containers consolidated from 6 to 2 (CONTAINER_DEFAULT and
CONTAINER_CUSTOM), removing tests that belong to FTL's own suite
- Tests now focus on Docker-specific behaviour: entrypoint, signal
handling, UID/GID mapping, cron setup, and password assignment
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Adam Warner <me@adamwarner.co.uk>
* Added new docker tag variations to specify the debian version ('stretch', and 'buster').
* Arch images are alway as specific as possible: pihole/pihole:master-amd64-stretch
* Multiarch images have both the specific debian version tags as well as the generic non-debian tags: pihole/pihole:master-stretch & pihole/pihole:master
* Currently, the non-specific tags point to the 'stretch' images. Eventaully it can be migrated to 'buster'.
* Use GitHub actions to do the builds. Although the script names include 'gh-actions' to differentiate them from the 'circle' scripts, there is zero logic that is specific to Github (ie. no Github environment variables).
* 'armhf:buster' & 'arm64:buster' has an issue with `ip route get`. I think the issue is related to 'qemu', but I'm not sure. Update the `validate_env` function to only use `ip route get` if `nc` reports something strange.
Signed-off-by: Daniel <daniel@developerdan.com>
- Tox py3.7 + pipenv
- Python3 Dockerfile.py
- Dockerfile.py tags remote instead of just local image names now
- Circle.sh instead of in-line circle.yml script breakout
- probably other stuff I forgot
- Docker images build during the tests should hopefullly now be available at the deploy job workflow thanks to shared docker layers.
- Rename aarch64 to arm64 to reduce custom map
* Submodules of pi-hole source for copying into docker images
* git submodules...yuk.
* debian builds and runs pi-hole apps/configs on jessie docker
* useful base line for merge and testing upstream updates
* Linux x86/64 image, would like to try raspian ARM docker image base too
* WIP alpine dockerfile
* will need more custom lighttpd config(s) at a minimum
* again there is an ARM alpine version so running on pi is future possibility
