Add example that shows the stated "default" settings in json

[rrauenza]

(also fix an errant . )

Description

Add an example that matches the stated defaults.

It isn't obvious from current docs that json requires only a single '=' sign. Also the "type" settings all need to be in one string, so this gives an example showing that.

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	39e6af4
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/675746718f1eb0000879b951
😎 Deploy Preview	https://deploy-preview-21596--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[rrauenza]

.... I see the lint error, but I'm also not convinced this feature actually works.

I'm gonna open a bug to clarify.

[dvdksn]

Thank you, but I would like to wait with this change. The buildkitd gc config has changed in v0.18, and so has the defaults. While that version doesn't yet ship with Docker Engine, it soon will and I'll need to make space for both the old and the new config format (incl. buildkitd and daemon.json)

[dvdksn]

Inaccuracy on my part, the buildkitd toml config actually changed in v0.17 so it is in the latest version of docker engine.

I'll address these updates separately.

[rrauenza]

So that would also address moby/buildkit#5581 ? With the == / = behavior?

[dvdksn]

Hmm, no I don't think the filters are affected by the new config options. KeepBytes was replaced by three, more configurable options in v0.17. GC config via daemon.json does not yet use all of these new options. But I don't believe filtering was changed, it only gave new ways to define the GC threshold (min reserved bytes, maximum used space, min free disk space)

[docker-robot]

Thanks for the pull request. We'd like to make our product docs better, but haven’t been able to review all the suggestions.
As our docs have also diverged, we do not have the bandwidth to review and rebase old pull requests.

If the updates are still relevant, review our contribution guidelines and rebase your pull request against the latest version of the docs, then mark it as fresh with a /remove-lifecycle stale comment.
If not, this pull request will be closed in 30 days. This helps our maintainers focus on the active pull requests.

Prevent pull requests from auto-closing with a /lifecycle frozen comment.

/lifecycle stale