nit: maybe reuse the context for all the calls ? 🤔

There is another ForceRemove defer inside the dispatch function

Good catch @tonistiigi. I'll put remove handling in the global dispatch function.

Perhaps making these two separate conditions (small bit of duplication, but may be better to understand without having to add comments to explain)

if d.builder.options.ForceRemove {
	d.builder.containerManager.RemoveAll(d.builder.Stdout)
	return
}
if d.builder.options.Remove && err == nil {
	d.builder.containerManager.RemoveAll(d.builder.Stdout)
	return
}

One thing I was wondering; it --rm=false, should --force-remove still remove containers? Can you check on an older version?

If that's the case, then it should likely look like:

if !d.builder.options.Remove {
	return
}
if err == nil || d.builder.options.ForceRemove {
	d.builder.containerManager.RemoveAll(d.builder.Stdout)
}

@thaJeztah on options deserialization, there is a reconcilation that forces rm to true if force-rm is true:

	if httputils.BoolValue(r, "forcerm") && versions.GreaterThanOrEqualTo(version, "1.12") {
		options.Remove = true
	} else if r.FormValue("rm") == "" && versions.GreaterThanOrEqualTo(version, "1.12") {
		options.Remove = true
	} else {
		options.Remove = httputils.BoolValue(r, "rm")
	}

You can use https://golang.org/pkg/testing/#T.Run so that all test cases run even if one of the require fail.

Maybe TestBuildWithRemoveAndForceRemove or something like that? Intermediate containers seem like more of the test result than the test condition. And this tests both failures and non-failures, so failures doesn't seem relevant to the name.

If you use t.Run() you can use this extra string as the test name so that any assert/require failure has this extra information associated with it, instead of just the last assert.Equal()

This will make it impossible to run the test in parallel with any other test that creates containers.

Instead of counting the total number of containers I think it would be possible to parse the build output and grab the container ids. Then attempt to list or inspect the containers with those ids to see if they exist.

Can you remove the blank lines between the github.com... dependencies, and make sure they're sorted correctly?

import (
	"archive/tar"
	"bytes"
	"context"
	"encoding/json"
	"io"
	"strings"
	"testing"

	"github.com/docker/docker/api/types"
	"github.com/docker/docker/api/types/filters"
	"github.com/docker/docker/integration/util/request"
	"github.com/docker/docker/pkg/jsonmessage"
	"github.com/stretchr/testify/require"
)

These names could be a lot more descriptive. The dashes can also be spaces, testing.Run() will take care of adding the dashes.

• "successful build with no removal"
• "successful build with remove"
• "successful build with remove and force remove"
• "failed build with no removal"
  ...

this cleanup will be missed if require.NoError(t, err) fails the test, could be deferred.

parsing of ids from the response would be great in a separate function to keep the test more readable.