docs: update buildgc example config to use new buildkit v0.17 options

[dvdksn]

Signed-off-by: David Karlsson 35727626+dvdksn@users.noreply.github.com

- What I did

Updated the example builder gc config in the dockerd reference to use the new
options introduced in buildkit v0.17.

- How I did it

Tested manually

A couple small inconsistencies I noticed when doing this:

• The filter field in daemon.json uses a single = to assign filters, whereas builder uses ==, for example: type==source.git.checkout
• The size values in daemon.json are human-readable bytes. But BuildKit also allows percentage values. Attempting to set eg "minFreeSpace": "20%" results in config parse error.

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[thaJeztah]

@crazy-max was this one good to go, or changes needed?

[tonistiigi]

afaics this is called defaultReservedSpace

[crazy-max]

yes this is defaultReservedSpace: https://github.com/moby/moby/blob/e7d7771bce74e6120b472c02fd59d0d950f043d3/daemon/config/builder.go#L89

[thaJeztah]

The struct doesn't set an explicit JSON name; does that mean it's technically with a capital D? Is that something we should change in moby to be explicit if we want it to be lowercase?

[tonistiigi]

Parsing is case-insensitive

[thaJeztah]

Parsing is case-insensitive

Yes, and no; the default is to do fuzzy matching, and Go will pick the best match, but in a struct like this, case matters;

type Foo struct {
	Hello string
	HELLO string `json:"hello"`
}

If no name is given, the default name used when marshaling is CamelCase, so without explicitly specifying the JSON label, it means that it would be fune unmarshaling defaultReservedSpace, but when marshaling, it would use DefaultReservedSpace, which could happen if the daemon would either print its config, or write it to disk.

JSON-schema also isn't case-insensitive, so if we'd wanted to provide a schema for these files, we should be explicit, and same for Go's JSON "v2" that's currently being worked on; https://go.dev/blog/jsonv2-exp

[dvdksn]

Updated

[thaJeztah]

LGTM