7841aea292
This is a continuation of #8189 and #8085. When doing a `docker build` command, if the `--pull` command is not specified or set to `false` the pullOption used is `PullifMissing`. This causes the build to pull the image only if it is not present in local storage. It also will raise an error if the image is not found in the registry (or the registry is down), even if the image is present in local storage. If the `--pull` command IS specified or specified with an argument of `true`, the build will always pull the image from the registries. This uses the pullOption `PullAlways`. It also will raise an error if the image is not found in the registry, even if the image is present in local storage. These changes now brings the pull functionality for `podman build` into line with `docker build`. However, I consider this to be a breaking change. Previously if you did `podman build --pull`, `podman build` or `podman build --pull = true`, then the image would be pulled from the registry if there was not an image in local storage or if the image in the registry was newer than the one in local storage. An error would *NOT* be raised if there was not an image in the registry or the registry was down as long as there was a copy in the local storage. An error would be raised if the image could not be retrieved from both the registry and local storage. This is the PullOption `PullIfNewer`. I believe this also differs from what Buildah does at this time but I'm too beat to chase that down at the moment. Personally I'd like to use the `PullIfNewer` for at least `--pull` and `--pull=true` so that you don't get an error if the registry has a network hiccup and the image is already stored locally. But this differs from Docker. I'd like to post scrum about this at our next stand up to make sure we're all on the same page about the ramifications of this change. Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
Podman Documentation
The online man pages and other documents regarding Podman can be found at Read The Docs. The man pages can be found under the Commands link on that page.
Build the Docs
Directory Structure
| Directory | |
|---|---|
| Markdown source for man pages | docs/source/markdown/ |
| man pages aliases as .so files | docs/source/markdown/links/ |
| restructured text for readthedocs.io | docs/rst/ |
| target for output | docs/build |
| man pages | docs/build/man |
| remote linux man pages | docs/build/remote/linux |
| remote darwin man pages | docs/build/remote/darwin |
| remote windows html pages | docs/build/remote/windows |
Support files
| docs/remote-docs.sh | Read the docs/source/markdown files and format for each platform |
| docs/links-to-html.lua | pandoc filter to do aliases for html files |
API Reference
The latest online documentation is
automatically generated by two cooperating automation systems based on committed upstream
source code. Firstly, the Cirrus-CI docs task builds
pkg/api/swagger.yaml and uploads it to a public-facing location (Google Storage Bucket -
an online service for storing unstructured data). Second, Read The Docs
reacts to the github.com repository change, building the content for the libpod documentation
site. This site includes for the API section,
some javascript which consumes the uploaded swagger.yaml file directly from the Google
Storage Bucket.
Since there are multiple systems and local cache is involved, it's possible that updates to documentation (especially the swagger/API docs) will lag by 10-or-so minutes. However, because the client (i.e. your web browser) is fetching content from multiple locations that do not share a common domain, accessing the API section may show a stack-trace similar to the following:
If reloading the page, or clearing your local cache does not fix the problem, it is
likely caused by broken metadata needed to protect clients from cross-site-scripting
style attacks. Please notify a maintainer
so they may investigate how/why the swagger.yaml file's CORS-metadata is
incorrect, or the file isn't accessable for some other reason.