Add contributor guidelines for where to put source code in packages#49950
Add contributor guidelines for where to put source code in packages#49950vvoland merged 1 commit intomoby:masterfrom
Conversation
CONTRIBUTING.md
Outdated
| - `docs` - All Moby technical documentation using markdown | ||
| - `hack` - All scripts used for testing, development, and CI | ||
| - `integration` - Testing the integration of the API, client, and daemon | ||
| - `integration-cli` - Testing the integration of the docker cli with the daemon |
There was a problem hiding this comment.
integration-cli tests are deprecated and we have a CI check that asserts that.
We should probably suggest adding an e2e in https://github.com/docker/cli instead.
There was a problem hiding this comment.
Thats a good point, I didn't realize e2e was moved to the cli but makes sense
thaJeztah
left a comment
There was a problem hiding this comment.
derp; had a pending review that I didn't submit; probably incomplete
CONTRIBUTING.md
Outdated
| - `hack` - All scripts used for testing, development, and CI | ||
| - `integration` - Testing the integration of the API, client, and daemon | ||
| - `integration-cli` - Testing the integration of the docker cli with the daemon | ||
| - `man`- All Moby reference manuals used for the `man` command |
There was a problem hiding this comment.
The man pages directly relate to the binaries produced for the daemon; we should make sure that these are part of the daemon module (as that must contain all the material used to produce the daemon packages)
| - `client` - All Go files for the docker client | ||
| - `contrib` - Files, configurations, and packages related to external tools or libraries | ||
| - `daemon` - All Go files and packages for building the daemon | ||
| - `docs` - All Moby technical documentation using markdown |
There was a problem hiding this comment.
We'll likely need to split the docs per module as well; we have docs for the API, which should be part of the API module, and docs for the daemon and daemon configuration file (some of which still to be transferred back from the CLI repository). Given that those have a direct relation to each of those modules, should probably be split for each?
CONTRIBUTING.md
Outdated
| configuration and build files, no source files will be accepted in the root. | ||
|
|
||
| - `api` - All types shared by client and daemon along with swagger definitions. | ||
| - `bundles` - Autogenerated during build, do not check in files here |
There was a problem hiding this comment.
This one is in .gitignore, and not in the repository, so probably not worth including here?
CONTRIBUTING.md
Outdated
| - `docs` - All Moby technical documentation using markdown | ||
| - `hack` - All scripts used for testing, development, and CI | ||
| - `integration` - Testing the integration of the API, client, and daemon | ||
| - `integration-cli` - Testing the integration of the docker cli with the daemon |
There was a problem hiding this comment.
Probably should call out that no new tests should be added here. The remaining tests in this package should still be split between integration and/or moved to docker/cli e2e tests. Quite some tests are "abusing" the CLI to test the API (which should be in integration/) and some are testing CLI behavior (which should be moved to docker/cli);
austinvazquez
left a comment
There was a problem hiding this comment.
LGTM, pretty straightforward coming from someone who didn't grow up with the historical organization. :)
Signed-off-by: Derek McGowan <derek@mcg.dev>
08055b0 to
071d27c
Compare
As discussed in maintainer call, before making large package and module moves, clearly layout the intended package structure in the contributing docs.
The layout is still open to discussion, the current idea is first we will create the
apimodule, theclientmodule, and then thedaemonmodule. The root will continue to be me module-less for the next release to prevent new tags from breaking existing importers of package. More research is being still being done to measure the impact of making changes to the root module.Related to #49873