Cleanup: new project docs fix-ups (alternative)
This cleans up the recently added project docs and fixes some minor issues. - remove inline styles where possible - add redirects for renamed/replaced documents - add styles for GitHub labels to match the style on GitHub - fix minor markdown issues causing some code-blocks to be shown as text - wrap the documents to 80-chars - use 4 spaces in stead of tabs for identing and remove trailing whitespace/redundant blank lines - optimized 'gordon' image NOTE: This alternative commit/PR re-introduces some inline styles because the docs/base image has not yet been updated for the current docs. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn
parent
faa6fd40f4
commit
efc625fcd0
|
|
@ -36,7 +36,10 @@
|
|||
{ "Condition": { "KeyPrefixEquals": "examples/using_supervisord/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "articles/using_supervisord/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "reference/api/registry_index_spec/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "reference/api/hub_registry_spec/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "use/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "examples/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "installation/openSUSE/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "installation/SUSE/" } }
|
||||
{ "Condition": { "KeyPrefixEquals": "installation/openSUSE/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "installation/SUSE/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "contributing/contributing/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/who-written-for/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "contributing/devenvironment/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/set-up-prereqs/" } },
|
||||
{ "Condition": { "KeyPrefixEquals": "contributing/docs_style-guide/" }, "Redirect": { "HostName": "$BUCKET", "ReplaceKeyPrefixWith": "project/doc-style/" } }
|
||||
]
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -4,15 +4,23 @@ page_keywords: contribute, project, design, refactor, proposal
|
|||
|
||||
# Advanced contributing
|
||||
|
||||
In this section, you learn about the more advanced contributions you can make. They are advanced because they have a more involved workflow or require greater programming experience. Don't be scared off though, if you like to stretch and challenge yourself, this is the place for you.
|
||||
In this section, you learn about the more advanced contributions you can make.
|
||||
They are advanced because they have a more involved workflow or require greater
|
||||
programming experience. Don't be scared off though, if you like to stretch and
|
||||
challenge yourself, this is the place for you.
|
||||
|
||||
This section gives generalized instructions for advanced contributions. You'll read about the workflow but there are not specific descriptions of commands. Your goal should be to understand the processes described.
|
||||
This section gives generalized instructions for advanced contributions. You'll
|
||||
read about the workflow but there are not specific descriptions of commands.
|
||||
Your goal should be to understand the processes described.
|
||||
|
||||
At this point, you should have read and worked through the earlier parts of the project contributor guide. You should also have <a href="../make-a-contribution" target="_blank"> made at least one project contribution</a>.
|
||||
At this point, you should have read and worked through the earlier parts of
|
||||
the project contributor guide. You should also have
|
||||
<a href="../make-a-contribution/" target="_blank"> made at least one project contribution</a>.
|
||||
|
||||
## Refactor or cleanup proposal
|
||||
|
||||
A refactor or cleanup proposal changes Docker's internal structure without altering the external behavior. To make this type of proposal:
|
||||
A refactor or cleanup proposal changes Docker's internal structure without
|
||||
altering the external behavior. To make this type of proposal:
|
||||
|
||||
1. Fork `docker/docker`.
|
||||
|
||||
|
|
@ -35,11 +43,16 @@ A refactor or cleanup proposal changes Docker's internal structure without alter
|
|||
|
||||
## Design proposal
|
||||
|
||||
A design proposal solves a problem or adds a feature to the Docker software. The process for submitting design proposals requires two pull requests, one for the design and one for the implementation.
|
||||
A design proposal solves a problem or adds a feature to the Docker software.
|
||||
The process for submitting design proposals requires two pull requests, one
|
||||
for the design and one for the implementation.
|
||||
|
||||
|
||||
|
||||
The important thing to notice is that both the design pull request and the implementation pull request go through a review. In other words, there is considerable time commitment in a design proposal; so, you might want to pair with someone on design work.
|
||||
The important thing to notice is that both the design pull request and the
|
||||
implementation pull request go through a review. In other words, there is
|
||||
considerable time commitment in a design proposal; so, you might want to pair
|
||||
with someone on design work.
|
||||
|
||||
The following provides greater detail on the process:
|
||||
|
||||
|
|
@ -58,7 +71,7 @@ The following provides greater detail on the process:
|
|||
|
||||
3. Talk to the community about your idea.
|
||||
|
||||
We have lots of <a href="../get-help" target="_blank">community forums</a>
|
||||
We have lots of <a href="../get-help/" target="_blank">community forums</a>
|
||||
where you can get feedback on your idea. Float your idea in a forum or two
|
||||
to get some commentary going on it.
|
||||
|
||||
|
|
@ -73,7 +86,7 @@ The following provides greater detail on the process:
|
|||
|
||||
7. Write a proposal for your change into the file.
|
||||
|
||||
This is a markdown file that describes your idea. Your proposal
|
||||
This is a Markdown file that describes your idea. Your proposal
|
||||
should include information like:
|
||||
|
||||
* Why is this changed needed or what are the use cases?
|
||||
|
|
|
|||
|
|
@ -4,22 +4,26 @@ page_keywords: change, commit, squash, request, pull request, test, unit test, i
|
|||
|
||||
# Coding Style Checklist
|
||||
|
||||
This checklist summarizes the material you experienced working through [make a code contribution](/project/make-a-contribution) and [advanced contributing](/project/advanced-contributing). The checklist applies to code that is program code or code that is documentation code.
|
||||
This checklist summarizes the material you experienced working through [make a
|
||||
code contribution](/project/make-a-contribution) and [advanced
|
||||
contributing](/project/advanced-contributing). The checklist applies to code
|
||||
that is program code or code that is documentation code.
|
||||
|
||||
## Change and commit code
|
||||
|
||||
* Fork the `docker/docker` repository.
|
||||
|
||||
* Make changes on your fork in a feature branch. Name your branch `XXXX-something` where `XXXX` is the issue number you are working on.
|
||||
* Make changes on your fork in a feature branch. Name your branch `XXXX-something`
|
||||
where `XXXX` is the issue number you are working on.
|
||||
|
||||
* Run `gofmt -s -w file.go` on each changed file before
|
||||
committing your changes. Most editors have plug-ins that do this automatically.
|
||||
committing your changes. Most editors have plug-ins that do this automatically.
|
||||
|
||||
* Update the documentation when creating or modifying features.
|
||||
|
||||
* Commits that fix or close an issue should reference them in the commit message
|
||||
`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
|
||||
issue on a merge.
|
||||
`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
|
||||
issue on a merge.
|
||||
|
||||
* After every commit, run the test suite and ensure it is passing.
|
||||
|
||||
|
|
@ -27,7 +31,8 @@ issue on a merge.
|
|||
|
||||
* Set your `git` signature and make sure you sign each commit.
|
||||
|
||||
* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the Git history.
|
||||
* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the
|
||||
Git history.
|
||||
|
||||
## Tests and testing
|
||||
|
||||
|
|
@ -37,40 +42,52 @@ issue on a merge.
|
|||
|
||||
* Use existing Docker test files (`name_test.go`) for inspiration.
|
||||
|
||||
* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your branch before submitting a pull request.
|
||||
* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your
|
||||
branch before submitting a pull request.
|
||||
|
||||
* Run `make docs` to build the documentation and then check it locally.
|
||||
|
||||
* Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
|
||||
checker</a> or similar to test you documentation changes for clarity, concision,
|
||||
and correctness.
|
||||
checker</a> or similar to test you documentation changes for clarity,
|
||||
concision, and correctness.
|
||||
|
||||
## Pull requests
|
||||
|
||||
* Sync and cleanly rebase on top of Docker's `master` without multiple branches
|
||||
mixed into the PR.
|
||||
mixed into the PR.
|
||||
|
||||
* Before the pull request, squash your commits into logical units of work using `git rebase -i` and `git push -f`.
|
||||
* Before the pull request, squash your commits into logical units of work using
|
||||
`git rebase -i` and `git push -f`.
|
||||
|
||||
* Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
* Include documentation changes in the same commit so that a revert would
|
||||
remove all traces of the feature or fix.
|
||||
|
||||
* Reference each issue in your pull request description (`#XXXX`)
|
||||
|
||||
## Respond to pull requests reviews
|
||||
|
||||
* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments to indicate acceptance.
|
||||
* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments
|
||||
to indicate acceptance.
|
||||
|
||||
* Code review comments may be added to your pull request. Discuss, then make the
|
||||
suggested modifications and push additional commits to your feature branch.
|
||||
* Code review comments may be added to your pull request. Discuss, then make
|
||||
the suggested modifications and push additional commits to your feature
|
||||
branch.
|
||||
|
||||
* Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
|
||||
* Incorporate changes on your feature branch and push to your fork. This
|
||||
automatically updates your open pull request.
|
||||
|
||||
* Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
|
||||
* Post a comment after pushing to alert reviewers to PR changes; pushing a
|
||||
change does not send notifications.
|
||||
|
||||
* A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR.
|
||||
* A change requires LGTMs from an absolute majority maintainers of an
|
||||
affected component. For example, if you change `docs/` and `registry/` code,
|
||||
an absolute majority of the `docs/` and the `registry/` maintainers must
|
||||
approve your PR.
|
||||
|
||||
## Merges after pull requests
|
||||
|
||||
* After a merge, [a master build](https://master.dockerproject.com/) is available almost immediately.
|
||||
* After a merge, [a master build](https://master.dockerproject.com/) is
|
||||
available almost immediately.
|
||||
|
||||
* If you made a documentation change, you can see it at [docs.master.dockerproject.com](http://docs.master.dockerproject.com/).
|
||||
* If you made a documentation change, you can see it at
|
||||
[docs.master.dockerproject.com](http://docs.master.dockerproject.com/).
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ exactly what they see in their shell:
|
|||
|
||||
* Indent shell examples by 4 spaces so they get rendered as code blocks.
|
||||
* Start typed commands with `$ ` (dollar space), so that they are easily
|
||||
differentiated from program output.
|
||||
differentiated from program output.
|
||||
* Program output has no prefix.
|
||||
* Comments begin with # (hash space).
|
||||
* In-container shell commands, begin with `$$ ` (dollar dollar space).
|
||||
|
|
@ -232,7 +232,7 @@ following:
|
|||
* Point out potential issues or questions
|
||||
* Ask for help from experts in the company or the community
|
||||
* Encourage feedback from core developers and others involved in creating the
|
||||
software being documented.
|
||||
software being documented.
|
||||
|
||||
Writing a PR that is singular in focus and has clear objectives will encourage
|
||||
all of the above. Done correctly, the process allows reviewers (maintainers and
|
||||
|
|
|
|||
|
|
@ -2,41 +2,75 @@ page_title: Where to chat or get help
|
|||
page_description: Describes Docker's communication channels
|
||||
page_keywords: IRC, Google group, Twitter, blog, Stackoverflow
|
||||
|
||||
<style>
|
||||
/* @TODO add 'no-zebra' table-style to the docs-base stylesheet */
|
||||
/* Table without "zebra" striping */
|
||||
.content-body table.no-zebra tr {
|
||||
background-color: transparent;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Where to chat or get help
|
||||
|
||||
There are several communications channels you can use to chat with Docker community members and developers.
|
||||
There are several communications channels you can use to chat with Docker
|
||||
community members and developers.
|
||||
|
||||
<!-- TODO (@thaJeztah) remove after docs/base is updated -->
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;text-align: left;}
|
||||
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
|
||||
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
|
||||
.tg th{font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<col width="25%">
|
||||
<col width="75%">
|
||||
<tr>
|
||||
<td class="tg-031e">Internet Relay Chat (IRC)</th>
|
||||
<td class="tg-031e"><p>IRC a direct line to our most knowledgeable Docker users. The <code>#docker</code> and <code>#docker-dev</code> group on <strong>irc.freenode.net</strong>. IRC was first created in 1988. So, it is a rich chat protocol but it can overwhelm new users. You can search <a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.</p>
|
||||
Read our IRC quickstart guide below for an easy way to get started.</th>
|
||||
<td>Internet Relay Chat (IRC)</th>
|
||||
<td>
|
||||
<p>
|
||||
IRC a direct line to our most knowledgeable Docker users.
|
||||
The <code>#docker</code> and <code>#docker-dev</code> group on
|
||||
<strong>irc.freenode.net</strong>. IRC was first created in 1988.
|
||||
So, it is a rich chat protocol but it can overwhelm new users. You can search
|
||||
<a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.
|
||||
</p>
|
||||
Read our IRC quickstart guide below for an easy way to get started.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">Google Groups</td>
|
||||
<td class="tg-031e">There are two groups. <a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a> is for people using Docker containers. The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a> group is for contributors and other people contributing to the Docker project.</td>
|
||||
<td>Google Groups</td>
|
||||
<td>
|
||||
There are two groups.
|
||||
<a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a>
|
||||
is for people using Docker containers.
|
||||
The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a>
|
||||
group is for contributors and other people contributing to the Docker
|
||||
project.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">Twitter</td>
|
||||
<td class="tg-031e">You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's twitter</a> to get updates on our products. You can also tweet us questions or just share blogs or stories.</td>
|
||||
<td>Twitter</td>
|
||||
<td>
|
||||
You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's twitter</a>
|
||||
to get updates on our products. You can also tweet us questions or just
|
||||
share blogs or stories.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">Stackoverflow</td>
|
||||
<td class="tg-031e">Stackoverflow has over 7000K Docker questions listed. We regularly monitor <a href="http://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a> and so do many other knowledgeable Docker users.</td>
|
||||
<td>Stack Overflow</td>
|
||||
<td>
|
||||
Stack Overflow has over 7000K Docker questions listed. We regularly
|
||||
monitor <a href="http://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a>
|
||||
and so do many other knowledgeable Docker users.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
## IRC Quickstart
|
||||
|
||||
IRC can also be overwhelming for new users. This quickstart shows you the easiest way to connect to IRC.
|
||||
IRC can also be overwhelming for new users. This quickstart shows you
|
||||
the easiest way to connect to IRC.
|
||||
|
||||
1. In your browser open <a href="http://webchat.freenode.net" target="_blank">http://webchat.freenode.net</a>
|
||||
|
||||
|
|
@ -45,25 +79,26 @@ IRC can also be overwhelming for new users. This quickstart shows you the easies
|
|||
|
||||
2. Fill out the form.
|
||||
|
||||
<!-- TODO (@thaJeztah) remove after docs/base is updated -->
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;}
|
||||
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
.tg {border-collapse:collapse;border-spacing:0;}
|
||||
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
.tg th{font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg no-zebra" style="width: auto">
|
||||
<tr>
|
||||
<th class="tg-031e"><b>Nickname</b></th>
|
||||
<th class="tg-031e">The short name you want to be known as in IRC.</th>
|
||||
<td><b>Nickname</b></td>
|
||||
<td>The short name you want to be known as in IRC.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e"><b>Channels</b></td>
|
||||
<td class="tg-031e"><code>#docker</code></td>
|
||||
<td><b>Channels</b></td>
|
||||
<td><code>#docker</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e"><b>reCAPTCHA</b></td>
|
||||
<td class="tg-031e">Use the value provided.</td>
|
||||
<td><b>reCAPTCHA</b></td>
|
||||
<td>Use the value provided.</td>
|
||||
</tr>
|
||||
</table>
|
||||
</table>
|
||||
|
||||
3. Click "Connect".
|
||||
|
||||
|
|
@ -76,7 +111,7 @@ IRC can also be overwhelming for new users. This quickstart shows you the easies
|
|||
|
||||
4. In the command line, register your nickname.
|
||||
|
||||
/msg nickserv REGISTER password youremail@example.com
|
||||
/msg NickServ REGISTER password youremail@example.com
|
||||
|
||||
|
||||
|
||||
|
|
@ -108,7 +143,8 @@ IRC can also be overwhelming for new users. This quickstart shows you the easies
|
|||
|
||||
### Tips and learning more about IRC
|
||||
|
||||
Next time you return to log into chat, you'll need to re-enter your password on the command line using this command:
|
||||
Next time you return to log into chat, you'll need to re-enter your password
|
||||
on the command line using this command:
|
||||
|
||||
/msg NickServ identify <password>
|
||||
|
||||
|
|
@ -116,4 +152,8 @@ If you forget or lose your password see <a
|
|||
href="https://freenode.net/faq.shtml#sendpass" target="_blank">the FAQ on
|
||||
freenode.net</a> to learn how to recover it.
|
||||
|
||||
This quickstart was meant to get you up and into IRC very quickly. If you find IRC useful there is a lot more to learn. Drupal, another open source project, actually has <a href="https://www.drupal.org/irc/setting-up" target="_blank">written a lot of good documentation about using IRC</a> for their project (thanks Drupal!).
|
||||
This quickstart was meant to get you up and into IRC very quickly. If you find
|
||||
IRC useful there is a lot more to learn. Drupal, another open source project,
|
||||
actually has <a href="https://www.drupal.org/irc/setting-up" target="_blank">
|
||||
written a lot of good documentation about using IRC</a> for their project
|
||||
(thanks Drupal!).
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 20 KiB |
|
|
@ -2,28 +2,78 @@ page_title: Make a project contribution
|
|||
page_description: Basic workflow for Docker contributions
|
||||
page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
|
||||
|
||||
|
||||
<!-- TODO (@thaJeztah) remove after docs/base is updated -->
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
|
||||
.tg td {background-color: #fff;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
|
||||
.tg th {font-weight:bold;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
|
||||
.tg .tg-e3zv{width:150px;}
|
||||
</style>
|
||||
|
||||
<style>
|
||||
|
||||
/* GitHub label styles */
|
||||
.gh-label {
|
||||
display: inline-block;
|
||||
padding: 3px 4px;
|
||||
font-size: 11px;
|
||||
font-weight: bold;
|
||||
line-height: 1;
|
||||
color: #fff;
|
||||
border-radius: 2px;
|
||||
box-shadow: inset 0 -1px 0 rgba(0,0,0,0.12);
|
||||
}
|
||||
|
||||
.gh-label.black-belt { background-color: #000000; color: #ffffff; }
|
||||
.gh-label.bug { background-color: #fc2929; color: #ffffff; }
|
||||
.gh-label.improvement { background-color: #bfe5bf; color: #2a332a; }
|
||||
.gh-label.project-doc { background-color: #207de5; color: #ffffff; }
|
||||
.gh-label.white-belt { background-color: #ffffff; color: #333333; }
|
||||
|
||||
</style>
|
||||
|
||||
# Make a project contribution
|
||||
|
||||
Contributing is a process where you work with Docker maintainers and the community to improve Docker. There is a formal process for contributing. We try to keep our contribution process simple so you want to come back.
|
||||
Contributing is a process where you work with Docker maintainers and the
|
||||
community to improve Docker. There is a formal process for contributing.
|
||||
We try to keep our contribution process simple so you want to come back.
|
||||
|
||||
|
||||
In this section, you will create a new branch and work on some Docker code that you choose. Before you work through this process, take a few minutes to read through the next section which explains our basic contribution workflow.
|
||||
In this section, you will create a new branch and work on some Docker code
|
||||
that you choose. Before you work through this process, take a few minutes to
|
||||
read through the next section which explains our basic contribution workflow.
|
||||
|
||||
## The basic contribution workflow
|
||||
|
||||
You are about to work through our basic contribution workflow by fixing a single *white-belt* issue in the `docker/docker` repository. The workflow for fixing simple issues looks like this:
|
||||
You are about to work through our basic contribution workflow by fixing a
|
||||
single *white-belt* issue in the `docker/docker` repository. The workflow
|
||||
for fixing simple issues looks like this:
|
||||
|
||||
|
||||
|
||||
All Docker repositories have code and documentation. This workflow works for either content type. For example, you can find and fix doc or code issues. Also, you can propose a new Docker feature or propose a new Docker tutorial.
|
||||
All Docker repositories have code and documentation. This workflow works
|
||||
for either content type. For example, you can find and fix doc or code issues.
|
||||
Also, you can propose a new Docker feature or propose a new Docker tutorial.
|
||||
|
||||
Some workflow stages have slight differences for code or documentation contributions. When you reach that point in the flow, we make sure to tell you.
|
||||
Some workflow stages have slight differences for code or documentation
|
||||
contributions. When you reach that point in the flow, we make sure to tell you.
|
||||
|
||||
## Find and claim an existing issue
|
||||
|
||||
An existing issue is something reported by a Docker user. As issues come in, our maintainers triage them. Triage is its own topic. For now, it is important for you to know that triage includes ranking issues according to difficulty.
|
||||
An existing issue is something reported by a Docker user. As issues come in,
|
||||
our maintainers triage them. Triage is its own topic. For now, it is important
|
||||
for you to know that triage includes ranking issues according to difficulty.
|
||||
|
||||
Triaged issues have either a **white-belt** or **black-belt** label. A **white-belt** issue is considered an easier issue. Issues can have more than one the **white-belt** label, for example, **bug**, **improvement**, **/project/doc**, and so forth. These other labels are their for filtering purposes but you might also find them helpful.
|
||||
Triaged issues have either a <strong class="gh-label white-belt">white-belt</strong>
|
||||
or <strong class="gh-label black-belt">black-belt</strong> label.
|
||||
A <strong class="gh-label white-belt">white-belt</strong> issue is considered
|
||||
an easier issue. Issues can have more than one label, for example,
|
||||
<strong class="gh-label bug">bug</strong>,
|
||||
<strong class="gh-label improvement">improvement</strong>,
|
||||
<strong class="gh-label project-doc">project/doc</strong>, and so forth.
|
||||
These other labels are there for filtering purposes but you might also find
|
||||
them helpful.
|
||||
|
||||
In the next procedure, you find and claim an open white-belt issue.
|
||||
|
||||
|
|
@ -37,11 +87,11 @@ In the next procedure, you find and claim an open white-belt issue.
|
|||
|
||||
|
||||
|
||||
3. Look for the **white-belt** items on the list.
|
||||
3. Look for the <strong class="gh-label white-belt">white-belt</strong> items on the list.
|
||||
|
||||
4. Click on the "Labels" dropdown and select **white-belt**.
|
||||
4. Click on the "labels" dropdown and select <strong class="gh-label white-belt">white-belt</strong>.
|
||||
|
||||
The system filters to show only open **white-belt** issues.
|
||||
The system filters to show only open <strong class="gh-label white-belt">white-belt</strong> issues.
|
||||
|
||||
5. Open an issue that interests you.
|
||||
|
||||
|
|
@ -53,9 +103,9 @@ In the next procedure, you find and claim an open white-belt issue.
|
|||
We don't allow external contributors to assign issues to themselves, so you
|
||||
need to read the comments to find if a user claimed an issue by saying:
|
||||
|
||||
* "I'd love to give this a try~"
|
||||
* "I'll work on this!"
|
||||
* "I'll take this."
|
||||
- "I'd love to give this a try~"
|
||||
- "I'll work on this!"
|
||||
- "I'll take this."
|
||||
|
||||
The community is very good about claiming issues explicitly.
|
||||
|
||||
|
|
@ -70,7 +120,11 @@ In the next procedure, you find and claim an open white-belt issue.
|
|||
|
||||
## Sync your fork and create a new branch
|
||||
|
||||
If you have followed along in this guide, you forked the `docker/docker` repository. Maybe that was an hour ago or a few days ago. In any case, before you start working on your issue, sync your repository with the upstream `docker/docker` master. Syncing ensures your repository has the latest changes.
|
||||
If you have followed along in this guide, you forked the `docker/docker`
|
||||
repository. Maybe that was an hour ago or a few days ago. In any case, before
|
||||
you start working on your issue, sync your repository with the upstream
|
||||
`docker/docker` master. Syncing ensures your repository has the latest
|
||||
changes.
|
||||
|
||||
To sync your repository:
|
||||
|
||||
|
|
@ -147,8 +201,6 @@ To sync your repository:
|
|||
To https://github.com/moxiegirl/docker.git
|
||||
8e107a9..5035fa1 master -> master
|
||||
|
||||
If you check
|
||||
|
||||
9. Create a new feature branch to work on your issue.
|
||||
|
||||
Your branch name should have the format `XXXX-descriptive` where `XXXX` is
|
||||
|
|
@ -172,7 +224,11 @@ To sync your repository:
|
|||
|
||||
## Work on your issue
|
||||
|
||||
The work you do for your issue depends on the specific issue you picked. This section gives you a step-by-step workflow. Where appropriate, it provides command examples. However, this is a generalized workflow, depending on your issue you may you may repeat steps or even skip some. How much time it takes you depends on you --- you could spend days or 30 minutes of your time.
|
||||
The work you do for your issue depends on the specific issue you picked.
|
||||
This section gives you a step-by-step workflow. Where appropriate, it provides
|
||||
command examples. However, this is a generalized workflow, depending on your
|
||||
issue you may you may repeat steps or even skip some. How much time it takes
|
||||
you depends on you --- you could spend days or 30 minutes of your time.
|
||||
|
||||
Follow this workflow as you work:
|
||||
|
||||
|
|
@ -210,20 +266,20 @@ Follow this workflow as you work:
|
|||
|
||||
5. Format your source files correctly.
|
||||
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
|
||||
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
|
||||
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:bold;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
|
||||
.tg .tg-e3zv{width:150px;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<thead>
|
||||
<tr>
|
||||
<th class="tg-e3zv">File type</th>
|
||||
<th class="tg-031e">How to format</th>
|
||||
<th>How to format</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="tg-e3zv"><code>.go</code></td>
|
||||
<td class="tg-031e"><p>Format <code>.go</code> files using the <code>gofmt</code> command. For example, if you edited the `docker.go` file you would format the file
|
||||
<td>
|
||||
<p>
|
||||
Format <code>.go</code> files using the <code>gofmt</code> command.
|
||||
For example, if you edited the `docker.go` file you would format the file
|
||||
like this:
|
||||
</p>
|
||||
<p><code>$ gofmt -s -w file.go</code></p>
|
||||
|
|
@ -234,12 +290,12 @@ Follow this workflow as you work:
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-e3zv"><code>.md</code> and non-<code>.go</code> files</td>
|
||||
<td class="tg-031e">Wrap lines to 80 characters.</td>
|
||||
<td class="tg-e3zv" style="white-space: nowrap"><code>.md</code> and non-<code>.go</code> files</td>
|
||||
<td>Wrap lines to 80 characters.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
6. List your changes.
|
||||
|
||||
$ git status
|
||||
|
|
@ -281,7 +337,11 @@ Follow this workflow as you work:
|
|||
|
||||
## Create a pull request to docker/docker
|
||||
|
||||
A pull request sends your code to the Docker maintainers for review. Your pull request goes from your forked repository to the `docker/docker` repository. You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the list of active pull requests to Docker</a> on GitHub.
|
||||
A pull request sends your code to the Docker maintainers for review. Your pull
|
||||
request goes from your forked repository to the `docker/docker` repository.
|
||||
You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the
|
||||
list of active pull requests to Docker</a>
|
||||
on GitHub.
|
||||
|
||||
To create a pull request for your change:
|
||||
|
||||
|
|
@ -352,7 +412,8 @@ To create a pull request for your change:
|
|||
|
||||
|
||||
|
||||
The pull request compares your changes to the `master` branch on the `docker/docker` repository.
|
||||
The pull request compares your changes to the `master` branch on the
|
||||
`docker/docker` repository.
|
||||
|
||||
11. Edit the dialog's description and add a reference to the issue you are fixing.
|
||||
|
||||
|
|
@ -376,17 +437,30 @@ To create a pull request for your change:
|
|||
|
||||
## Your pull request under review
|
||||
|
||||
At this point, your pull request is reviewed. The first reviewer is Gordon. He might who might look slow in this picture:
|
||||
At this point, your pull request is reviewed. The first reviewer is Gordon.
|
||||
He might who might look slow in this picture:
|
||||
|
||||
|
||||
|
||||
He is actually pretty fast over a network. He checks your pull request (PR) for common problems like missing signatures. If Gordon finds a problem, he'll send an email to your GitHub user.
|
||||
He is actually pretty fast over a network. He checks your pull request (PR)
|
||||
for common problems like missing signatures. If Gordon finds a problem, he'll
|
||||
send an email to your GitHub user.
|
||||
|
||||
After Gordon, the core Docker maintainers look at your pull request and comment on it. The shortest comment you might see is `LGTM` which means **l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that is a good thing, you passed that review.
|
||||
After Gordon, the core Docker maintainers look at your pull request and comment
|
||||
on it. The shortest comment you might see is `LGTM` which means
|
||||
**l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that is a good thing,
|
||||
you passed that review.
|
||||
|
||||
For complex changes, maintainers may ask you questions or ask you to change something about your submission. All maintainer comments on a PR go to the email address associated with your GitHub account. Any GitHub user who "participates" in a PR receives an email to. Participating means creating or commenting on a PR.
|
||||
For complex changes, maintainers may ask you questions or ask you to change
|
||||
something about your submission. All maintainer comments on a PR go to the
|
||||
email address associated with your GitHub account. Any GitHub user who
|
||||
"participates" in a PR receives an email to. Participating means creating or
|
||||
commenting on a PR.
|
||||
|
||||
Our maintainers are very experienced Docker users and open source contributors. So, they value your time and will try to work efficiently with you by keeping their comments specific and brief. If they ask you to make a change, you'll need to update your pull request with additional changes.
|
||||
Our maintainers are very experienced Docker users and open source contributors.
|
||||
So, they value your time and will try to work efficiently with you by keeping
|
||||
their comments specific and brief. If they ask you to make a change, you'll
|
||||
need to update your pull request with additional changes.
|
||||
|
||||
To update your existing pull request:
|
||||
|
||||
|
|
@ -427,11 +501,17 @@ To update your existing pull request:
|
|||
mention that you updated your PR. Your comment alerts the maintainers that
|
||||
you made an update.
|
||||
|
||||
A change requires LGTMs from an absolute majority of an affected component's maintainers. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR. Once you get approval, we merge your pull request into Docker's `master` cod branch.
|
||||
A change requires LGTMs from an absolute majority of an affected component's
|
||||
maintainers. For example, if you change `docs/` and `registry/` code, an
|
||||
absolute majority of the `docs/` and the `registry/` maintainers must approve
|
||||
your PR. Once you get approval, we merge your pull request into Docker's
|
||||
`master` code branch.
|
||||
|
||||
## After the merge
|
||||
|
||||
It can take time to see a merged pull request in Docker's official release. A master build is available almost immediately though. Docker builds and updates its development binaries after each merge to `master`.
|
||||
It can take time to see a merged pull request in Docker's official release.
|
||||
A master build is available almost immediately though. Docker builds and
|
||||
updates its development binaries after each merge to `master`.
|
||||
|
||||
1. Browse to <a href="https://master.dockerproject.com/" target="_blank">https://master.dockerproject.com/</a>.
|
||||
|
||||
|
|
@ -444,10 +524,17 @@ It can take time to see a merged pull request in Docker's official release. A ma
|
|||
|
||||
4. View any documentation changes at <a href="http://docs.master.dockerproject.com/" target="_blank">docs.master.dockerproject.com</a>.
|
||||
|
||||
Once you've verified everything merged, feel free to delete your feature branch from your fork. For information on how to do this, <a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">see the GitHub help on deleting branches</a>.
|
||||
Once you've verified everything merged, feel free to delete your feature branch
|
||||
from your fork. For information on how to do this,
|
||||
<a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">
|
||||
see the GitHub help on deleting branches</a>.
|
||||
|
||||
## Where to go next
|
||||
|
||||
At this point, you have completed all the basic tasks in our contributors guide. If you enjoyed contributing, let us know by completing another **white-belt** issue or two. We really appreciate the help.
|
||||
At this point, you have completed all the basic tasks in our contributors guide.
|
||||
If you enjoyed contributing, let us know by completing another
|
||||
<strong class="gh-label white-belt">white-belt</strong>
|
||||
issue or two. We really appreciate the help.
|
||||
|
||||
If you are very experienced and want to make a major change, go onto [learn about advanced contributing](/project/advanced-contributing).
|
||||
If you are very experienced and want to make a major change, go onto
|
||||
[learn about advanced contributing](/project/advanced-contributing).
|
||||
|
|
|
|||
|
|
@ -2,6 +2,14 @@ page_title: Work with a development container
|
|||
page_description: How to use Docker's development environment
|
||||
page_keywords: development, inception, container, image Dockerfile, dependencies, Go, artifacts
|
||||
|
||||
|
||||
<!-- TODO (@thaJeztah) remove after docs/base is updated -->
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;}
|
||||
.tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
.tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
|
||||
# Work with a development container
|
||||
|
||||
In this section, you learn to develop like a member of Docker's core team.
|
||||
|
|
@ -11,15 +19,22 @@ dependencies: system libraries and binaries, go environment, go dependencies,
|
|||
etc.
|
||||
|
||||
Docker's development environment is itself, ultimately a Docker container.
|
||||
You use the `docker` repository and its `Dockerfile` to create a Docker image, run a Docker container, and develop code in the container. Docker itself builds, tests, and releases new Docker versions using this container.
|
||||
|
||||
If you followed the procedures that <a href="../set-up-prereqs" target="_blank">set up the prerequisites</a>, you should have a fork of the
|
||||
`docker/docker` repository. You also created a branch called `dry-run-test`. In this section, you continue working with your fork on this branch.
|
||||
You use the `docker` repository and its `Dockerfile` to create a Docker image,
|
||||
run a Docker container, and develop code in the container. Docker itself builds,
|
||||
tests, and releases new Docker versions using this container.
|
||||
|
||||
If you followed the procedures that <a href="../set-up-prereqs" target="_blank">
|
||||
set up the prerequisites</a>, you should have a fork of the `docker/docker`
|
||||
repository. You also created a branch called `dry-run-test`. In this section,
|
||||
you continue working with your fork on this branch.
|
||||
|
||||
## Clean your host of Docker artifacts
|
||||
|
||||
Docker developers run the latest stable release of the Docker software; Or Boot2docker and Docker if their machine is Mac OS X. They clean their local hosts of unnecessary Docker artifacts such as stopped containers or unused images. Cleaning unnecessary artifacts isn't strictly necessary but it is good practice, so it is included here.
|
||||
Docker developers run the latest stable release of the Docker software; Or
|
||||
Boot2docker and Docker if their machine is Mac OS X. They clean their local
|
||||
hosts of unnecessary Docker artifacts such as stopped containers or unused
|
||||
images. Cleaning unnecessary artifacts isn't strictly necessary but it is
|
||||
good practice, so it is included here.
|
||||
|
||||
To remove unnecessary artifacts.
|
||||
|
||||
|
|
@ -29,19 +44,15 @@ To remove unnecessary artifacts.
|
|||
|
||||
You should see something similar to the following:
|
||||
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:10px
|
||||
5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<table class="tg code">
|
||||
<tr>
|
||||
<th class="tg-031e">CONTAINER ID</th>
|
||||
<th class="tg-031e">IMAGE</th>
|
||||
<th class="tg-031e">COMMAND</th>
|
||||
<th class="tg-031e">CREATED</th>
|
||||
<th class="tg-031e">STATUS</th>
|
||||
<th class="tg-031e">PORTS</th>
|
||||
<th class="tg-031e">NAMES</th>
|
||||
<th>CONTAINER ID</th>
|
||||
<th>IMAGE</th>
|
||||
<th>COMMAND</th>
|
||||
<th>CREATED</th>
|
||||
<th>STATUS</th>
|
||||
<th>PORTS</th>
|
||||
<th>NAMES</th>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -55,17 +66,13 @@ To remove unnecessary artifacts.
|
|||
|
||||
You should see something similar to the following:
|
||||
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:10px
|
||||
5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<table class="tg code">
|
||||
<tr>
|
||||
<th class="tg-031e">REPOSITORY</th>
|
||||
<th class="tg-031e">TAG</th>
|
||||
<th class="tg-031e">IMAGE ID</th>
|
||||
<th class="tg-031e">CREATED</th>
|
||||
<th class="tg-031e">VIRTUAL SIZE</th>
|
||||
<th>REPOSITORY</th>
|
||||
<th>TAG</th>
|
||||
<th>IMAGE ID</th>
|
||||
<th>CREATED</th>
|
||||
<th>VIRTUAL SIZE</th>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -85,7 +92,9 @@ To remove unnecessary artifacts.
|
|||
|
||||
## Build an image
|
||||
|
||||
If you followed the last procedure, your host is clean of unnecessary images and containers. In this section, you build an image from the Docker development environment.
|
||||
If you followed the last procedure, your host is clean of unnecessary images
|
||||
and containers. In this section, you build an image from the Docker development
|
||||
environment.
|
||||
|
||||
1. Open a terminal.
|
||||
|
||||
|
|
@ -118,59 +127,56 @@ If you followed the last procedure, your host is clean of unnecessary images and
|
|||
$ docker images
|
||||
|
||||
You should see something similar to this:
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:5px
|
||||
5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
|
||||
<table class="tg code">
|
||||
<tr>
|
||||
<th class="tg-031e">REPOSTITORY</th>
|
||||
<th class="tg-031e">TAG</th>
|
||||
<th class="tg-031e">IMAGE ID</th>
|
||||
<th class="tg-031e">CREATED</th>
|
||||
<th class="tg-031e">VIRTUAL SIZE</th>
|
||||
<th>REPOSTITORY</th>
|
||||
<th>TAG</th>
|
||||
<th>IMAGE ID</th>
|
||||
<th>CREATED</th>
|
||||
<th>VIRTUAL SIZE</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">dry-run-test</td>
|
||||
<td class="tg-031e">latest</td>
|
||||
<td class="tg-031e">663fbee70028</td>
|
||||
<td class="tg-031e">About a minute ago</td>
|
||||
<td class="tg-031e"></td>
|
||||
<td>dry-run-test</td>
|
||||
<td>latest</td>
|
||||
<td>663fbee70028</td>
|
||||
<td>About a minute ago</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">ubuntu</td>
|
||||
<td class="tg-031e">trusty</td>
|
||||
<td class="tg-031e">2d24f826cb16</td>
|
||||
<td class="tg-031e">2 days ago</td>
|
||||
<td class="tg-031e">188.3 MB</td>
|
||||
<td>ubuntu</td>
|
||||
<td>trusty</td>
|
||||
<td>2d24f826cb16</td>
|
||||
<td>2 days ago</td>
|
||||
<td>188.3 MB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">ubuntu</td>
|
||||
<td class="tg-031e">trusty-20150218.1</td>
|
||||
<td class="tg-031e">2d24f826cb16</td>
|
||||
<td class="tg-031e">2 days ago</td>
|
||||
<td class="tg-031e">188.3 MB</td>
|
||||
<td>ubuntu</td>
|
||||
<td>trusty-20150218.1</td>
|
||||
<td>2d24f826cb16</td>
|
||||
<td>2 days ago</td>
|
||||
<td>188.3 MB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">ubuntu</td>
|
||||
<td class="tg-031e">14.04</td>
|
||||
<td class="tg-031e">2d24f826cb16</td>
|
||||
<td class="tg-031e">2 days ago</td>
|
||||
<td class="tg-031e">188.3 MB</td>
|
||||
<td>ubuntu</td>
|
||||
<td>14.04</td>
|
||||
<td>2d24f826cb16</td>
|
||||
<td>2 days ago</td>
|
||||
<td>188.3 MB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">ubuntu</td>
|
||||
<td class="tg-031e">14.04.2</td>
|
||||
<td class="tg-031e">2d24f826cb16</td>
|
||||
<td class="tg-031e">2 days ago</td>
|
||||
<td class="tg-031e">188.3 MB</td>
|
||||
<td>ubuntu</td>
|
||||
<td>14.04.2</td>
|
||||
<td>2d24f826cb16</td>
|
||||
<td>2 days ago</td>
|
||||
<td>188.3 MB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">ubuntu</td>
|
||||
<td class="tg-031e">latest</td>
|
||||
<td class="tg-031e">2d24f826cb16</td>
|
||||
<td class="tg-031e">2 days ago</td>
|
||||
<td class="tg-031e">188.3 MB</td>
|
||||
<td>ubuntu</td>
|
||||
<td>latest</td>
|
||||
<td>2d24f826cb16</td>
|
||||
<td>2 days ago</td>
|
||||
<td>188.3 MB</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -237,6 +243,7 @@ build and run a `docker` binary in your container.
|
|||
4. From the `/go/src/github.com/docker/docker` directory make a `docker` binary with the `make.sh` script.
|
||||
|
||||
root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh binary
|
||||
|
||||
You only call `project/make.sh` to build a binary _inside_ a Docker
|
||||
development container as you are now. On your host, you'll use `make`
|
||||
commands (more about this later).
|
||||
|
|
@ -249,7 +256,6 @@ build and run a `docker` binary in your container.
|
|||
Created package {:path=>"lxc-docker-1.5.0-dev_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
|
||||
Created package {:path=>"lxc-docker_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
|
||||
|
||||
|
||||
5. List all the contents of the `binary` directory.
|
||||
|
||||
root@5f8630b873fe:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary/
|
||||
|
|
@ -286,28 +292,24 @@ build and run a `docker` binary in your container.
|
|||
|
||||
$ docker ps
|
||||
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:5px
|
||||
5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<table class="tg code">
|
||||
<tr>
|
||||
<th class="tg-031e">CONTAINER ID</th>
|
||||
<th class="tg-031e">IMAGE</th>
|
||||
<th class="tg-031e">COMMAND</th>
|
||||
<th class="tg-031e">CREATED</th>
|
||||
<th class="tg-031e">STATUS</th>
|
||||
<th class="tg-031e">PORTS</th>
|
||||
<th class="tg-031e">NAMES</th>
|
||||
<th>CONTAINER ID</th>
|
||||
<th>IMAGE</th>
|
||||
<th>COMMAND</th>
|
||||
<th>CREATED</th>
|
||||
<th>STATUS</th>
|
||||
<th>PORTS</th>
|
||||
<th>NAMES</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">474f07652525</td>
|
||||
<td class="tg-031e">dry-run-test:latest</td>
|
||||
<td class="tg-031e">"hack/dind /bin/bash</td>
|
||||
<td class="tg-031e">14 minutes ago</td>
|
||||
<td class="tg-031e">Up 14 minutes</td>
|
||||
<td class="tg-031e"></td>
|
||||
<td class="tg-031e">tender_shockley</td>
|
||||
<td>474f07652525</td>
|
||||
<td>dry-run-test:latest</td>
|
||||
<td>"hack/dind /bin/bash</td>
|
||||
<td>14 minutes ago</td>
|
||||
<td>Up 14 minutes</td>
|
||||
<td></td>
|
||||
<td>tender_shockley</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -334,13 +336,15 @@ build and run a `docker` binary in your container.
|
|||
|
||||
## Restart a container with your source
|
||||
|
||||
At this point, you have experienced the "Docker inception" technique. That is, you have:
|
||||
At this point, you have experienced the "Docker inception" technique. That is,
|
||||
you have:
|
||||
|
||||
* built a Docker image from the Docker repository
|
||||
* created and started a Docker development container from that image
|
||||
* built a Docker binary inside of your Docker development container
|
||||
* launched a `docker` daemon using your newly compiled binary
|
||||
* called the `docker` client to run a `hello-world` container inside your development container
|
||||
* called the `docker` client to run a `hello-world` container inside
|
||||
your development container
|
||||
|
||||
When you really get to developing code though, you'll want to iterate code
|
||||
changes and builds inside the container. For that you need to mount your local
|
||||
|
|
@ -404,12 +408,12 @@ container.
|
|||
* start `docker -dD` to launch the Docker daemon inside the container
|
||||
* run `docker ps` on local host to get the development container's name
|
||||
* connect to your running container `docker exec -it container_name bash`
|
||||
* use the `docker run hello-world` command to create and run a container inside your development container
|
||||
|
||||
* use the `docker run hello-world` command to create and run a container
|
||||
inside your development container
|
||||
|
||||
## Where to go next
|
||||
|
||||
Congratulations, you have successfully achieved Docker inception. At this point, you've set up your development environment and verified almost all the essential processes you need to contribute. Of course, before you start contributing, [you'll need to learn one more piece of the development environment, the test framework](/project/test-and-docs/).
|
||||
|
||||
|
||||
|
||||
Congratulations, you have successfully achieved Docker inception. At this point,
|
||||
you've set up your development environment and verified almost all the essential
|
||||
processes you need to contribute. Of course, before you start contributing,
|
||||
[you'll need to learn one more piece of the development environment, the test framework](/project/test-and-docs/).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@ page_keywords: GitHub account, repository, clone, fork, branch, upstream, Git, G
|
|||
|
||||
# Set up the prerequisites
|
||||
|
||||
Work through this page to set up the software and host environment you need to contribute. You'll find instructions for configuring your `git` repository and creating a fork you'll use later in the guide.
|
||||
Work through this page to set up the software and host environment you need to
|
||||
contribute. You'll find instructions for configuring your `git` repository and
|
||||
creating a fork you'll use later in the guide.
|
||||
|
||||
## Get the Required Software
|
||||
|
||||
|
|
@ -15,7 +17,9 @@ Before you begin contributing you must have:
|
|||
* `make`
|
||||
* `docker`
|
||||
|
||||
You'll notice that `go`, the language that Docker is written in, is not listed. That's because you don't need it installed; Docker's development environment provides it for you. You'll learn more about the development environment later.
|
||||
You'll notice that `go`, the language that Docker is written in, is not listed.
|
||||
That's because you don't need it installed; Docker's development environment
|
||||
provides it for you. You'll learn more about the development environment later.
|
||||
|
||||
### Get a GitHub account
|
||||
|
||||
|
|
@ -23,7 +27,8 @@ To contribute to the Docker project, you will need a <a
|
|||
href="https://github.com" target="_blank">GitHub account</a>. A free account is
|
||||
fine. All the Docker project repositories are public and visible to everyone.
|
||||
|
||||
You should also have some experience using both the GitHub application and `git` on the command line.
|
||||
You should also have some experience using both the GitHub application and `git`
|
||||
on the command line.
|
||||
|
||||
### Install git
|
||||
|
||||
|
|
@ -33,7 +38,8 @@ system and properly installed with the following command:
|
|||
$ git --version
|
||||
|
||||
|
||||
This documentation is written using `git` version 2.2.2. Your version may be different depending on your OS.
|
||||
This documentation is written using `git` version 2.2.2. Your version may be
|
||||
different depending on your OS.
|
||||
|
||||
### Install make
|
||||
|
||||
|
|
@ -42,11 +48,15 @@ command:
|
|||
|
||||
$ make -v
|
||||
|
||||
This documentation is written using GNU Make 3.81. Your version may be different depending on your OS.
|
||||
This documentation is written using GNU Make 3.81. Your version may be different
|
||||
depending on your OS.
|
||||
|
||||
### Install or upgrade Docker
|
||||
|
||||
If you haven't already, install the Docker software using the <a href="/installation" target="_blank">instructions for your operating system</a>. If you have an existing installation, check your version and make sure you have the latest Docker.
|
||||
If you haven't already, install the Docker software using the
|
||||
<a href="/installation" target="_blank">instructions for your operating system</a>.
|
||||
If you have an existing installation, check your version and make sure you have
|
||||
the latest Docker.
|
||||
|
||||
To check if `docker` is already installed on Linux:
|
||||
|
||||
|
|
@ -57,7 +67,6 @@ On Mac OS X or Windows, you should have installed Boot2Docker which includes
|
|||
Docker. You'll need to verify both Boot2Docker and then Docker. This
|
||||
documentation was written on OS X using the following versions.
|
||||
|
||||
|
||||
$ boot2docker version
|
||||
Boot2Docker-cli version: v1.5.0
|
||||
Git commit: ccd9032
|
||||
|
|
@ -67,12 +76,15 @@ documentation was written on OS X using the following versions.
|
|||
|
||||
## Linux users and sudo
|
||||
|
||||
This guide assumes you have added your user to the `docker` group on your system. To check, list the group's contents:
|
||||
This guide assumes you have added your user to the `docker` group on your system.
|
||||
To check, list the group's contents:
|
||||
|
||||
$ getent group docker
|
||||
docker:x:999:ubuntu
|
||||
|
||||
If the command returns no matches, you have two choices. You can preface this guide's `docker` commands with `sudo` as you work. Alternatively, you can add your user to the `docker` group as follows:
|
||||
If the command returns no matches, you have two choices. You can preface this
|
||||
guide's `docker` commands with `sudo` as you work. Alternatively, you can add
|
||||
your user to the `docker` group as follows:
|
||||
|
||||
$ sudo usermod -aG docker ubuntu
|
||||
|
||||
|
|
@ -82,7 +94,8 @@ You must log out and back in for this modification to take effect.
|
|||
## Fork and clone the Docker code
|
||||
|
||||
When contributing, you first fork the Docker code repository. A fork copies
|
||||
a repository at a particular point in time. GitHub tracks for you where a fork originates.
|
||||
a repository at a particular point in time. GitHub tracks for you where a fork
|
||||
originates.
|
||||
|
||||
As you make contributions, you change your fork's code. When you are ready,
|
||||
you make a pull request back to the original Docker repository. If you aren't
|
||||
|
|
@ -141,16 +154,23 @@ To fork and clone Docker:
|
|||
Take a moment to familiarize yourself with the repository's contents. List
|
||||
the contents.
|
||||
|
||||
|
||||
## Set your signature and an upstream remote
|
||||
|
||||
When you contribute to Docker, you must certify you agree with the <a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>. You indicate your agreement by signing your `git` commits like this:
|
||||
When you contribute to Docker, you must certify you agree with the
|
||||
<a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>.
|
||||
You indicate your agreement by signing your `git` commits like this:
|
||||
|
||||
Signed-off-by: Pat Smith <pat.smith@email.com>
|
||||
|
||||
To create a signature, you configure your username and email address in Git. You can set these globally or locally on just your `docker-fork` repository. You must sign with your real name. We don't accept anonymous contributions or contributions through pseudonyms.
|
||||
To create a signature, you configure your username and email address in Git.
|
||||
You can set these globally or locally on just your `docker-fork` repository.
|
||||
You must sign with your real name. We don't accept anonymous contributions or
|
||||
contributions through pseudonyms.
|
||||
|
||||
As you change code in your fork, you'll want to keep it in sync with the changes others make in the `docker/docker` repository. To make syncing easier, you'll also add a _remote_ called `upstream` that points to `docker/docker`. A remote is just another a project version hosted on the internet or network.
|
||||
As you change code in your fork, you'll want to keep it in sync with the changes
|
||||
others make in the `docker/docker` repository. To make syncing easier, you'll
|
||||
also add a _remote_ called `upstream` that points to `docker/docker`. A remote
|
||||
is just another a project version hosted on the internet or network.
|
||||
|
||||
To configure your username, email, and add a remote:
|
||||
|
||||
|
|
@ -194,13 +214,15 @@ To configure your username, email, and add a remote:
|
|||
upstream https://github.com/docker/docker.git (fetch)
|
||||
upstream https://github.com/docker/docker.git (push)
|
||||
|
||||
|
||||
|
||||
## Create and push a branch
|
||||
|
||||
As you change code in your fork, you make your changes on a repository branch. The branch name should reflect what you are working on. In this section, you create a branch, make a change, and push it up to your fork.
|
||||
As you change code in your fork, you make your changes on a repository branch.
|
||||
The branch name should reflect what you are working on. In this section, you
|
||||
create a branch, make a change, and push it up to your fork.
|
||||
|
||||
This branch is just for testing your config for this guide. The changes are part of a dry run so the branch name is going to be dry-run-test. To create an push the branch to your fork on GitHub:
|
||||
This branch is just for testing your config for this guide. The changes arepart
|
||||
of a dry run so the branch name is going to be dry-run-test. To create an push
|
||||
the branch to your fork on GitHub:
|
||||
|
||||
1. Open a terminal and go to the root of your `docker-fork`.
|
||||
|
||||
|
|
@ -260,7 +282,6 @@ This branch is just for testing your config for this guide. The changes are part
|
|||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 TEST.md
|
||||
|
||||
|
||||
Commit messages should have a short summary sentence of no more than 50
|
||||
characters. Optionally, you can also include a more detailed explanation
|
||||
after the summary. Separate the summary from any explanation with an empty
|
||||
|
|
@ -283,7 +304,6 @@ This branch is just for testing your config for this guide. The changes are part
|
|||
* [new branch] dry-run-test -> dry-run-test
|
||||
Branch dry-run-test set up to track remote branch dry-run-test from origin.
|
||||
|
||||
|
||||
9. Open your browser to Github.
|
||||
|
||||
10. Navigate to your Docker fork.
|
||||
|
|
@ -292,7 +312,7 @@ This branch is just for testing your config for this guide. The changes are part
|
|||
|
||||
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
||||
Congratulations, you have set up and validated the contributor requirements. In the next section you'll [learn how to set up and work in a Docker development container](/project/set-up-dev-env/).
|
||||
Congratulations, you have set up and validated the contributor requirements.
|
||||
In the next section you'll [learn how to set up and work in a Docker development container](/project/set-up-dev-env/).
|
||||
|
|
|
|||
|
|
@ -2,6 +2,13 @@ page_title: Run tests and test documentation
|
|||
page_description: Describes Docker's testing infrastructure
|
||||
page_keywords: make test, make docs, Go tests, gofmt, contributing, running tests
|
||||
|
||||
<!-- TODO (@thaJeztah) remove after docs/base is updated -->
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
|
||||
.tg td{padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
.tg th{padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
|
||||
</style>
|
||||
|
||||
# Run tests and test documentation
|
||||
|
||||
Contributing includes testing your changes. If you change the Docker code, you
|
||||
|
|
@ -9,9 +16,15 @@ may need to add a new test or modify an existing one. Your contribution could
|
|||
even be adding tests to Docker. For this reason, you need to know a little
|
||||
about Docker's test infrastructure.
|
||||
|
||||
Many contributors contribute documentation only. Or, a contributor makes a code contribution that changes how Docker behaves and that change needs documentation. For these reasons, you also need to know how to build, view, and test the Docker documentation.
|
||||
Many contributors contribute documentation only. Or, a contributor makes a code
|
||||
contribution that changes how Docker behaves and that change needs
|
||||
documentation. For these reasons, you also need to know how to build, view, and
|
||||
test the Docker documentation.
|
||||
|
||||
In this section, you run tests in the `dry-run-test` branch of your Docker fork. If you have followed along in this guide, you already have this branch. If you don't have this branch, you can create it or simply use another of your branches.
|
||||
In this section, you run tests in the `dry-run-test` branch of your Docker
|
||||
fork. If you have followed along in this guide, you already have this branch.
|
||||
If you don't have this branch, you can create it or simply use another of your
|
||||
branches.
|
||||
|
||||
## Understand testing at Docker
|
||||
|
||||
|
|
@ -23,51 +36,59 @@ href="http://golang.org/pkg/testing/" target="_blank">Go's testing package
|
|||
documentation</a> and the <a href="http://golang.org/cmd/go/#hdr-Test_packages"
|
||||
target="_blank">go test help</a>.
|
||||
|
||||
You are responsible for _unit testing_ your contribution when you add new or change existing Docker code. A unit test is a piece of code that invokes a single, small piece of code ( _unit of work_ ) to verify the unit works as expected.
|
||||
You are responsible for _unit testing_ your contribution when you add new or
|
||||
change existing Docker code. A unit test is a piece of code that invokes a
|
||||
single, small piece of code ( _unit of work_ ) to verify the unit works as
|
||||
expected.
|
||||
|
||||
Depending on your contribution, you may need to add _integration tests_. These are tests that combine two or more work units into one component. These work units each have unit tests and then, together, integration tests that test the interface between the components. The `integration` and `integration-cli` directories in the Docker repository contain integration test code.
|
||||
Depending on your contribution, you may need to add _integration tests_. These
|
||||
are tests that combine two or more work units into one component. These work
|
||||
units each have unit tests and then, together, integration tests that test the
|
||||
interface between the components. The `integration` and `integration-cli`
|
||||
directories in the Docker repository contain integration test code.
|
||||
|
||||
Testing is its own speciality. If you aren't familiar with testing techniques, there is a lot of information available to you on the Web. For now, you should understand that, the Docker maintainers may ask you to write a new test or change an existing one.
|
||||
Testing is its own speciality. If you aren't familiar with testing techniques,
|
||||
there is a lot of information available to you on the Web. For now, you should
|
||||
understand that, the Docker maintainers may ask you to write a new test or
|
||||
change an existing one.
|
||||
|
||||
### Run tests on your local host
|
||||
|
||||
Before submitting any code change, you should run the entire Docker test suite. The `Makefile` contains a target for the entire test suite. The target's name is simply `test`. The make file contains several targets for testing:
|
||||
Before submitting any code change, you should run the entire Docker test suite.
|
||||
The `Makefile` contains a target for the entire test suite. The target's name
|
||||
is simply `test`. The make file contains several targets for testing:
|
||||
|
||||
<style type="text/css">
|
||||
.tg {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
|
||||
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
|
||||
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
|
||||
.tg .tg-vyw9{font-family:"Courier New", Courier, monospace !important;}
|
||||
.tg .tg-e3zv{font-weight:bold}
|
||||
.make-target {font-family:"Courier New", Courier, monospace !important;}
|
||||
</style>
|
||||
<table class="tg">
|
||||
<tr>
|
||||
<th class="tg-e3zv">Target</th>
|
||||
<th class="tg-e3zv">What this target does</th>
|
||||
<th>Target</th>
|
||||
<th>What this target does</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">test</td>
|
||||
<td class="tg-031e">Run all the tests.</td>
|
||||
<td class="make-target">test</td>
|
||||
<td>Run all the tests.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">test-unit</td>
|
||||
<td class="tg-031e">Run just the unit tests.</td>
|
||||
<td class="make-target">test-unit</td>
|
||||
<td>Run just the unit tests.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">test-integration</td>
|
||||
<td class="tg-031e">Run just integration tests.</td>
|
||||
<td class="make-target">test-integration</td>
|
||||
<td>Run just integration tests.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">test-integration-cli</td>
|
||||
<td class="tg-031e">Run the test for the integration command line interface.</td>
|
||||
<td class="make-target">test-integration-cli</td>
|
||||
<td>Run the test for the integration command line interface.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">test-docker-py</td>
|
||||
<td class="tg-031e">Run the tests for Docker API client.</td>
|
||||
<td class="make-target">test-docker-py</td>
|
||||
<td>Run the tests for Docker API client.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-vyw9">docs-test</td>
|
||||
<td class="tg-031e">Runs the documentation test build.</td>
|
||||
<td class="make-target">docs-test</td>
|
||||
<td>Runs the documentation test build.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
@ -87,7 +108,8 @@ Run the entire test suite on your current repository:
|
|||
|
||||
$ make test
|
||||
|
||||
This command does several things, it creates a container temporarily for testing. Inside that container, the `make`:
|
||||
This command does several things, it creates a container temporarily for
|
||||
testing. Inside that container, the `make`:
|
||||
|
||||
* creates a new binary
|
||||
* cross-compiles all the binaries for the various operating systems
|
||||
|
|
@ -110,7 +132,10 @@ Run the entire test suite on your current repository:
|
|||
|
||||
### Run test targets inside the development container
|
||||
|
||||
If you are working inside a Docker development container, you use the `project/make.sh` script to run tests. The `project/make.sh` script doesn't have a single target that runs all the tests. Instead, you provide a single commmand line with multiple targets that does the same thing.
|
||||
If you are working inside a Docker development container, you use the
|
||||
`project/make.sh` script to run tests. The `project/make.sh` script doesn't
|
||||
have a single target that runs all the tests. Instead, you provide a single
|
||||
commmand line with multiple targets that does the same thing.
|
||||
|
||||
Try this now.
|
||||
|
||||
|
|
@ -118,7 +143,8 @@ Try this now.
|
|||
|
||||
2. Start a Docker development image.
|
||||
|
||||
If you are following along with this guide, you should have a `dry-run-test` image.
|
||||
If you are following along with this guide, you should have a
|
||||
`dry-run-test` image.
|
||||
|
||||
$ docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
|
||||
|
||||
|
|
@ -128,16 +154,21 @@ Try this now.
|
|||
|
||||
The tests run just as they did within your local host.
|
||||
|
||||
Of course, you can also run a subset of these targets too. For example, to run just the unit tests:
|
||||
|
||||
Of course, you can also run a subset of these targets too. For example, to run
|
||||
just the unit tests:
|
||||
|
||||
root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit
|
||||
|
||||
Most test targets require that you build these precursor targets first: `dynbinary binary cross`
|
||||
Most test targets require that you build these precursor targets first:
|
||||
`dynbinary binary cross`
|
||||
|
||||
|
||||
## Running individual or multiple named tests
|
||||
|
||||
You can use the `TESTFLAGS` environment variable to run a single test. The flag's value is passed as arguments to the `go test` command. For example, from your local host you can run the `TestBuild` test with this command:
|
||||
You can use the `TESTFLAGS` environment variable to run a single test. The
|
||||
flag's value is passed as arguments to the `go test` command. For example, from
|
||||
your local host you can run the `TestBuild` test with this command:
|
||||
|
||||
$ TESTFLAGS='-test.run \^TestBuild\$' make test
|
||||
|
||||
|
|
@ -147,9 +178,15 @@ To run the same test inside your Docker development container, you do this:
|
|||
|
||||
## If test under Boot2Docker fail do to space errors
|
||||
|
||||
Running the tests requires about 2GB of memory. If you are running your container on bare metal, that is you are not running with Boot2Docker, your Docker development container is able to take the memory it requires directly from your local host.
|
||||
Running the tests requires about 2GB of memory. If you are running your
|
||||
container on bare metal, that is you are not running with Boot2Docker, your
|
||||
Docker development container is able to take the memory it requires directly
|
||||
from your local host.
|
||||
|
||||
If you are running Docker using Boot2Docker, the VM uses 2048MB by default. This means you can exceed the memory of your VM running tests in a Boot2Docker environment. When the test suite runs out of memory, it returns errors similar to the following:
|
||||
If you are running Docker using Boot2Docker, the VM uses 2048MB by default.
|
||||
This means you can exceed the memory of your VM running tests in a Boot2Docker
|
||||
environment. When the test suite runs out of memory, it returns errors similar
|
||||
to the following:
|
||||
|
||||
server.go:1302 Error: Insertion failed because database is full: database or
|
||||
disk is full
|
||||
|
|
@ -157,7 +194,8 @@ If you are running Docker using Boot2Docker, the VM uses 2048MB by default. This
|
|||
utils_test.go:179: Error copy: exit status 1 (cp: writing
|
||||
'/tmp/docker-testd5c9-[...]': No space left on device
|
||||
|
||||
To increase the memory on your VM, you need to reinitialize the Boot2Docker VM with new memory settings.
|
||||
To increase the memory on your VM, you need to reinitialize the Boot2Docker VM
|
||||
with new memory settings.
|
||||
|
||||
1. Stop all running containers.
|
||||
|
||||
|
|
@ -206,9 +244,15 @@ href="http://www.mkdocs.org/" target="_blank">MkDocs</a> to build Docker's
|
|||
documentation. Of course, you don't need to install this generator
|
||||
to build the documentation, it is included with container.
|
||||
|
||||
You should always check your documentation for grammar and spelling. The best way to do this is with <a href="http://www.hemingwayapp.com/" target="_blank">an online grammar checker</a>.
|
||||
You should always check your documentation for grammar and spelling. The best
|
||||
way to do this is with <a href="http://www.hemingwayapp.com/"
|
||||
target="_blank">an online grammar checker</a>.
|
||||
|
||||
When you change a documentation source file, you should test your change locally to make sure your content is there and any links work correctly. You can build the documentation from the local host. The build starts a container and loads the documentation into a server. As long as this container runs, you can browse the docs.
|
||||
When you change a documentation source file, you should test your change
|
||||
locally to make sure your content is there and any links work correctly. You
|
||||
can build the documentation from the local host. The build starts a container
|
||||
and loads the documentation into a server. As long as this container runs, you
|
||||
can browse the docs.
|
||||
|
||||
1. In a terminal, change to the root of your `docker-fork` repository.
|
||||
|
||||
|
|
@ -253,10 +297,7 @@ When you change a documentation source file, you should test your change locally
|
|||
|
||||
## Where to go next
|
||||
|
||||
Congratulations, you have successfully completed the basics you need to understand the Docker test framework. In the next steps, you use what you have learned so far to [contribute to Docker by working on an issue](/project/make-a-contribution/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Congratulations, you have successfully completed the basics you need to
|
||||
understand the Docker test framework. In the next steps, you use what you have
|
||||
learned so far to [contribute to Docker by working on an
|
||||
issue](/project/make-a-contribution/).
|
||||
|
|
|
|||
|
|
@ -6,17 +6,31 @@ page_keywords: Gordon, introduction, turtle, machine, libcontainer, how to
|
|||
|
||||
This section of the documentation contains a guide for Docker users who want to
|
||||
contribute code or documentation to the Docker project. As a community, we
|
||||
share rules of behavior and interaction. Make sure you are familiar with the <a href="https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines" target="_blank">community guidelines</a> before continuing.
|
||||
share rules of behavior and interaction. Make sure you are familiar with the <a
|
||||
href="https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines"
|
||||
target="_blank">community guidelines</a> before continuing.
|
||||
|
||||
## Where and what you can contribute
|
||||
|
||||
The Docker project consists of not just one but several repositories on GitHub. So, in addition to the `docker/docker` repository, there is the `docker/libcontainer` repo, the `docker/machine` repo, and several more. Contribute to any of these and you contribute to the Docker project.
|
||||
The Docker project consists of not just one but several repositories on GitHub.
|
||||
So, in addition to the `docker/docker` repository, there is the
|
||||
`docker/libcontainer` repo, the `docker/machine` repo, and several more.
|
||||
Contribute to any of these and you contribute to the Docker project.
|
||||
|
||||
Not all Docker repositories use the Go language. Also, each repository has its own focus area. So, if you are an experienced contributor, think about contributing to a Docker repository that has a language or a focus area you are familiar with.
|
||||
Not all Docker repositories use the Go language. Also, each repository has its
|
||||
own focus area. So, if you are an experienced contributor, think about
|
||||
contributing to a Docker repository that has a language or a focus area you are
|
||||
familiar with.
|
||||
|
||||
If you are new to the open source community, to Docker, or to formal programming, you should start out contributing to the `docker/docker` repository. Why? Because this guide is written for that repository specifically.
|
||||
If you are new to the open source community, to Docker, or to formal
|
||||
programming, you should start out contributing to the `docker/docker`
|
||||
repository. Why? Because this guide is written for that repository specifically.
|
||||
|
||||
Finally, code or documentation isn't the only way to contribute. You can report an issue, add to discussions in our community channel, write a blog post, or take a usability test. You can even propose your own type of contribution. Right now we don't have a lot written about this yet, so just email <mailto:feedback@docker.com> if this type of contributing interests you.
|
||||
Finally, code or documentation isn't the only way to contribute. You can report
|
||||
an issue, add to discussions in our community channel, write a blog post, or
|
||||
take a usability test. You can even propose your own type of contribution.
|
||||
Right now we don't have a lot written about this yet, so just email
|
||||
<mailto:feedback@docker.com> if this type of contributing interests you.
|
||||
|
||||
## A turtle is involved
|
||||
|
||||
|
|
@ -26,11 +40,17 @@ Enough said.
|
|||
|
||||
## How to use this guide
|
||||
|
||||
This is written for the distracted, the overworked, the sloppy reader with fair `git` skills and a failing memory for the GitHub GUI. The guide attempts to explain how to use the Docker environment as precisely, predictably, and procedurally as possible.
|
||||
This is written for the distracted, the overworked, the sloppy reader with fair
|
||||
`git` skills and a failing memory for the GitHub GUI. The guide attempts to
|
||||
explain how to use the Docker environment as precisely, predictably, and
|
||||
procedurally as possible.
|
||||
|
||||
Users who are new to the Docker development environment should start by setting up their environment. Then, they should try a simple code change. After that, you should find something to work on or propose at totally new change.
|
||||
Users who are new to the Docker development environment should start by setting
|
||||
up their environment. Then, they should try a simple code change. After that,
|
||||
you should find something to work on or propose at totally new change.
|
||||
|
||||
If you are a programming prodigy, you still may find this documentation useful. Please feel free to skim past information you find obvious or boring.
|
||||
If you are a programming prodigy, you still may find this documentation useful.
|
||||
Please feel free to skim past information you find obvious or boring.
|
||||
|
||||
## How to get started
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue