Files
TomSweeneyRedHat 7841aea292 Match build pull functionality with Docker's
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>
2020-10-31 20:11:00 -04:00
..
2020-10-01 09:13:39 -04:00
2020-01-14 09:54:48 +01:00
2020-03-19 14:03:02 -04:00
2020-03-30 08:18:35 -07:00
2019-10-31 12:31:39 -05:00
2019-10-31 12:31:39 -05:00
2017-11-01 11:24:59 -04:00
2020-10-30 10:32:17 -04:00
2020-10-21 08:37:57 -04:00
2019-10-31 12:31:39 -05:00

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:

Javascript Stack Trace Image

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.