Allright, I’ve got around 30 minutes – let’s see if we can get this DOCKER_HOST environment variable that we set up a test for in the last post done!

And all of a sudden – maybe because I was just out drinking beer and eating great food with Bobben, who you might remember from the Habit Tracker Part Four blog post – I no longer feel the urge to blog about every minor step, I’m just gonna implement that shit! Here it is!

It works in the sense that the test is green. Buuuut – I also just noticed that some other tests in that class (DefaultDockerClientConfigTest) are not green when I run them in IntelliJ IDEA.

Did I screw something up?

First, to sanity check, I’m going to check out master and see if things work there.

Ok, they do work. So I definitely screwed something up.

Now, let’s slow down. Despite the beer.

Here’s one of the tests – not touched by me – that now fail:

class DefaultDockerClientConfigTest {
    // ...

    public void environmentDockerHost() throws Exception {

        // given docker host in env
        Map<String, String> env = new HashMap<>();
        env.put(DefaultDockerClientConfig.DOCKER_HOST, "tcp://baz:8768");
        // and it looks to be SSL disabled

        // given default cert path
        Properties systemProperties = new Properties();
        systemProperties.setProperty("", "someUserName");
        systemProperties.setProperty("user.home", homeDir());

        // when you build a config
        DefaultDockerClientConfig config = buildConfig(env, systemProperties);
        assertEquals(config.getDockerHost(), URI.create("tcp://baz:8768"));

    // ...

I have marked the line that fails with three “pointing up”-emojis and the text “THIS IS THE LINE THAT FAILS”. I hope you’ll find it.

The log output says:

java.lang.IllegalArgumentException: Input byte array has wrong 4-byte ending unit
	at java.base/java.util.Base64$Decoder.decode0(
	at java.base/java.util.Base64$Decoder.decode(
	at java.base/java.util.Base64$Decoder.decode(


When did I even introduce this bug? To be honest, I haven’t run the test suite consistently after each change.

Maybe it’s time for a git bisect! I haven’t used that in years!

First I do a git rebase master to make things a bit more understandable for myself. Then I do:

$ git bisect start
status: waiting for both good and bad commits
$ git bisect bad
status: waiting for good commit(s), bad commit known
$ git bisect good master
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[d0f9fc84a2e1c8427edfa38f7b023f76bfbbf581] Start of reading all docker context meta files

Allright, so we’ve started bisecting – doing a binary search for the commit that introduced the bad stuff.

But alas, the code at the current commit does not even compile. Sloppy me. That makes it hard to tell if it’s a “good” or “bad” commit, in the sense we’re interested in right now. One of the difficulties with git bisect-ing. But I’m gonna mark it as bad, and we’ll see what happens.

$ git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[2e07c5f4b47a7dbf2bbe37be454a6630530d9ef6] Add a main method to test the thing

I run the tests here, and it’s all green! Good commit!

$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[ca0727da2a06b16d4ea8860d099e2b1a9514c5c9] Start at reading context meta file

I run the tests here and I get the failures! Bad commit!

$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3359f0a06fc2c5d6b02b13e2eca6b05b8effbb1c] Read the docker config file earlier so we can use it to determine host

Bad commit here as well!

$ git bisect bad
3359f0a06fc2c5d6b02b13e2eca6b05b8effbb1c is the first bad commit
commit 3359f0a06fc2c5d6b02b13e2eca6b05b8effbb1c
Author: Simon Kågedal Reimer <>
Date:   Wed Nov 30 08:29:58 2022 +0100

    Read the docker config file earlier so we can use it to determine host

 .../dockerjava/core/ | 39 +++++++++++++++-------
 .../github/dockerjava/core/   |  4 +++
 .../core/        | 13 ++++----
 .../dockerjava/core/   |  5 ++-
 .../dockerjava/core/      |  3 +-
 5 files changed, 41 insertions(+), 23 deletions(-)

Allright! We have pinned down the commit that introduced the bad stuff. Let’s look at that tomorrow.

Continue reading about the invalid Base64