Skip to content

Generate YAML doc#747

Merged
crazy-max merged 1 commit intodocker:masterfrom
crazy-max:yaml-docs
Sep 2, 2021
Merged

Generate YAML doc#747
crazy-max merged 1 commit intodocker:masterfrom
crazy-max:yaml-docs

Conversation

@crazy-max
Copy link
Copy Markdown
Member

Use cli-docs-tool to generate Markdown and now YAML docs.

@thaJeztah I have not used a sub gomod to avoid copy-pasting "require(...)" from the main one. github.com/docker/cli-docs-tool will not be used by ./cmd/buildx as shown with the command below:

$ cd ./cmd/buildx/
$ go list -deps -f '{{define "M"}}{{.Path}}@{{.Version}}{{end}}{{with .Module}}{{if not .Main}}{{if .Replace}}{{template "M" .Replace}}{{else}}{{template "M" .}}{{end}}{{end}}{{end}}' | sort -u
cloud.google.com/[email protected]
github.com/agext/[email protected]
github.com/agl/[email protected]
github.com/apparentlymart/[email protected]
github.com/apparentlymart/go-textseg/[email protected]
github.com/beorn7/[email protected]
github.com/cenkalti/backoff/[email protected]
github.com/cespare/xxhash/[email protected]
github.com/compose-spec/[email protected]
github.com/containerd/[email protected]
github.com/containerd/[email protected]
github.com/containerd/[email protected]
github.com/containerd/[email protected]
github.com/davecgh/[email protected]
github.com/distribution/distribution/[email protected]
github.com/docker/[email protected]+incompatible
github.com/docker/[email protected]
github.com/docker/[email protected]+incompatible
github.com/docker/[email protected]
github.com/docker/[email protected]+incompatible
github.com/docker/[email protected]
github.com/docker/[email protected]
github.com/docker/[email protected]
github.com/docker/[email protected]
github.com/docker/[email protected]
github.com/fvbommel/[email protected]
github.com/go-logr/[email protected]
github.com/gofrs/[email protected]
github.com/gogo/[email protected]
github.com/gogo/[email protected]
github.com/golang/[email protected]
github.com/golang/[email protected]
github.com/google/[email protected]
github.com/google/[email protected]
github.com/google/[email protected]
github.com/google/[email protected]
github.com/googleapis/[email protected]
github.com/gorilla/[email protected]
github.com/grpc-ecosystem/[email protected]
github.com/grpc-ecosystem/[email protected]
github.com/hashicorp/[email protected]
github.com/hashicorp/hcl/[email protected]
github.com/imdario/[email protected]
github.com/joho/[email protected]
github.com/json-iterator/[email protected]
github.com/klauspost/[email protected]
github.com/mattn/[email protected]
github.com/matttproud/[email protected]
github.com/mitchellh/[email protected]
github.com/mitchellh/[email protected]
github.com/moby/[email protected]
github.com/moby/[email protected]
github.com/moby/sys/[email protected]
github.com/moby/sys/[email protected]
github.com/moby/[email protected]
github.com/modern-go/[email protected]
github.com/modern-go/[email protected]
github.com/morikuni/[email protected]
github.com/opencontainers/[email protected]
github.com/opencontainers/[email protected]
github.com/pkg/[email protected]
github.com/prometheus/[email protected]
github.com/prometheus/[email protected]
github.com/prometheus/[email protected]
github.com/prometheus/[email protected]
github.com/serialx/[email protected]
github.com/sirupsen/[email protected]
github.com/spf13/[email protected]
github.com/spf13/[email protected]
github.com/theupdateframework/[email protected]
github.com/tonistiigi/[email protected]
github.com/tonistiigi/[email protected]
github.com/tonistiigi/[email protected]
github.com/xeipuuv/[email protected]
github.com/xeipuuv/[email protected]
github.com/xeipuuv/[email protected]
github.com/zclconf/[email protected]
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/[email protected]
go.opentelemetry.io/[email protected]
go.opentelemetry.io/otel/exporters/otlp/otlptrace/[email protected]
go.opentelemetry.io/otel/exporters/otlp/otlptrace/[email protected]
go.opentelemetry.io/otel/exporters/otlp/[email protected]
go.opentelemetry.io/otel/[email protected]
go.opentelemetry.io/otel/[email protected]
go.opentelemetry.io/[email protected]
go.opentelemetry.io/proto/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
golang.org/x/[email protected]
google.golang.org/[email protected]
google.golang.org/[email protected]
google.golang.org/[email protected]
gopkg.in/[email protected]
gopkg.in/[email protected]
k8s.io/[email protected]
k8s.io/[email protected]
k8s.io/[email protected]
k8s.io/klog/[email protected]
k8s.io/[email protected]
sigs.k8s.io/structured-merge-diff/[email protected]
sigs.k8s.io/[email protected]

@crazy-max crazy-max requested review from thaJeztah and tonistiigi and removed request for tonistiigi August 24, 2021 22:58
Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Looks good.

The only thing we should discuss / look at / brainstorm is what the most practical location is for the generated yaml files. Does it work best if they're together in the same directory as the markdown files (what it currently does, i.e. /docs/reference/XXXX.yaml), or would it be more convenient to have them in their own directory (/docs/yaml/XXX.yaml (for example)).

Mostly thinking if the script at https://github.com/docker/docker.github.io/blob/master/_scripts/fetch-upstream-resources.sh would possibly need the markdown files to be put somewhere else, etc.

Comment thread go.mod Outdated
Comment thread go.mod
github.com/serialx/hashring v0.0.0-20190422032157-8b2912629002
github.com/sirupsen/logrus v1.8.1
github.com/spf13/cobra v1.1.1
github.com/spf13/cobra v1.2.1
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the (a) bit of the concern I had with not making it a submodule. (As it may unintentionally be "pushing" dependencies to newer versions).

The replace rules are a bit of a pain though, so I agree (at least for now) it's probably ok to keep it as-is.

@thaJeztah
Copy link
Copy Markdown
Member

Mostly thinking if the script at https://github.com/docker/docker.github.io/blob/master/_scripts/fetch-upstream-resources.sh would possibly need the markdown files to be put somewhere else, etc.

Of course, we could (should) decide if we want these files to be fetched when building the docs, or to store a copy there (as we currently do); in both cases, we will need to look what's more practical (separate directory, or together)

@crazy-max
Copy link
Copy Markdown
Member Author

crazy-max commented Aug 25, 2021

@thaJeztah

The only thing we should discuss / look at / brainstorm is what the most practical location is for the generated yaml files. Does it work best if they're together in the same directory as the markdown files (what it currently does, i.e. /docs/reference/XXXX.yaml), or would it be more convenient to have them in their own directory (/docs/yaml/XXX.yaml (for example)).

I think a flatten dir is ok to avoid maintenance cost if paths change in the future.

Of course, we could (should) decide if we want these files to be fetched when building the docs, or to store a copy there (as we currently do); in both cases, we will need to look what's more practical (separate directory, or together)

I think storing a copy on docker.github.io is better to track them as any other source code for reviews and so on. Also we should discuss about an auto repo sync like GitHub does on https://github.com/github/docs to be able to automatically create PR on changes. I think it would be great :)

Mostly thinking if the script at https://github.com/docker/docker.github.io/blob/master/_scripts/fetch-upstream-resources.sh would possibly need the markdown files to be put somewhere else, etc.

About this line, as of Git 2.19, this is possible to clone a subdir with git clone --filter.

@thaJeztah
Copy link
Copy Markdown
Member

I think a flatten dir is ok to avoid maintenance cost if paths change in the future.

My train of thought was that "separate" would;

  • keep generated and hand-written files separate
  • possibly, the reference dir could contain markdown that's not directly associated with a command (? not sure, perhaps those should be stored outside of reference)
  • will it be harder to navigate through GitHub if both are in the same directory?

Again, just thoughts, so not strongly attached to one or the other, but thought I'd "brain dump" them here

Signed-off-by: CrazyMax <[email protected]>
@crazy-max
Copy link
Copy Markdown
Member Author

PTAL @thaJeztah @tonistiigi

Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@crazy-max crazy-max merged commit c1c414e into docker:master Sep 2, 2021
@crazy-max crazy-max deleted the yaml-docs branch September 2, 2021 18:16
@tonistiigi
Copy link
Copy Markdown
Member

Why do we need to commit the generated yaml docs into the repo?

@crazy-max
Copy link
Copy Markdown
Member Author

crazy-max commented Sep 2, 2021

@tonistiigi To be able to fetch them from the docs repo (git clone ... v0.6.3). I'm not sure if we could put them somewhere else. Maybe another folder like @thaJeztah said?

@tonistiigi
Copy link
Copy Markdown
Member

Can't the fetcher just generate them. I'm fine that we have a dockerfile target etc. here to run the generator and we can test it in this CI. But if the yaml itself is just an input to some external tool then I don't think we need to commit in copies for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants