Introduce additional docker tags for the debian version.#635
Conversation
|
I know there is a lot in here to review. Any initial thoughts? Is the lack of debian-generic architecture tags a blocker? |
|
I haven't looked it over since I try to stay out of @diginc way with docker but I'll give it a view if I'm not stepping on any toes. |
|
@diginc need any help? |
| # nc won't throw any text based errors when it times out connecting to a valid IP, otherwise it complains about the DNS name being garbage | ||
| # if nc doesn't behave as we expect on a valid IP the routing table should be able to look it up and return a 0 retcode | ||
| if [[ "$(nc -4 -w1 -z "$ServerIP" 53 2>&1)" != "" ]] || ! ip route get "$ServerIP" > /dev/null ; then | ||
| if [[ "$(nc -4 -w1 -z "$ServerIP" 53 2>&1)" != "" ]] && ! ip route get "$ServerIP" > /dev/null ; then |
There was a problem hiding this comment.
if nc doesn't behave as we expect on a valid IP the routing table should be able to look it up and return a 0 retcode
The comment states netcat can be unreliable so ip route is a fallback, so it should be ||, not && shouldn't it?
There was a problem hiding this comment.
no, if nc fails with an ||, then ip route get will never run. && means that both will run each time, and if both nc and ip route get fail, then we know for sure it is no good. If either of them pass, then we can be reasonably sure its valid.
There was a problem hiding this comment.
The better solution would be to figure out why armhf:buster & arm64:buster has an issue with ip route get. I spent some time on it, but when I starting running into things involving qemu, I gave up.
There was a problem hiding this comment.
The confusing part is the they are both negative tests, so != && !=
| GIT_BRANCH=$(git rev-parse --abbrev-ref HEAD | sed "s/\//-/g") | ||
| GIT_TAG=$(git describe --tags --exact-match 2> /dev/null || true) | ||
|
|
||
| DEFAULT_DEBIAN_VERSION="stretch" |
There was a problem hiding this comment.
we have a sprawling amount of default variables / updates to make in different places when those defaults change. We don't need it immediately but at some point, I'd like to centralize them with a very early export of defaults in a centrally included envs.sh that the pipeline uses before any builds/tests/uploads run. variables in the pipeline would work as a central location too but consider executing issues executing locally may have when putting things in the pipelines. The version number could migrate to this environment export too potentially.
* 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>
lightswitch05
force-pushed
the
feature/introduce-debian-version-tags
branch
from
acfc8d1 to
752d83a
Compare
|
I removed the references to my repo. Thanks for taking the time to review this massive PR! |
|
This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there: |
4 participants
Introduce additional docker tags for the Debian version, allows building both stretch and buster images.
Description
stretch, andbuster).pihole/pihole:master-amd64-stretch. This is a bit of a breaking change, as there are no morepihole/pihole:master-amd64tags... not sure if that is a problem?pihole/pihole:master-stretch&pihole/pihole:masterbuster.armhf:buster&arm64:busterhas an issue withip route get. I think the issue is related toqemu, but I'm not sure. Update thevalidate_envfunction to only useip route getifncreports something strange.busterandstretchtags, other then getting them to build and pass tests, I haven't done any further verification of thebusterimagesMotivation and Context
How Has This Been Tested?
Types of changes
Checklist: