scattered inconsistency in podman docs markdown files
by Robert P. J. Day
this would be my OCD coming through, but as i'm crawling through the
man page markdown files, i see a lack of consistency in how various
objects are marked (and therefore possibly rendered).
using podman-run.1.md as a single example, it first appears that
commands are marked with double asterisks, as in:
"Run a process in a new container. **podman run** starts a process
with its own file system, its own networking, and its own isolated
process tree. The IMAGE which starts the process may define defaults
related to the process that will be run in the container, the
networking to expose, and more, but **podman run** ..."
ok, fair enough, so that's the standard for commands which, in a
simple terminal window, renders as bold.
on the other hand, filenames apparently use backqoutes:
"Several files will be automatically created within the container.
These include `/etc/hosts`, `/etc/hostname`, and `/etc/resolv.conf` to
manage networking..."
again, fair enough, except in the very next para, they're not
similarly marked:
"When running from a user defined network namespace, the
/etc/netns/NSNAME/resolv.conf will be used if it exists, otherwise
/etc/resolv.conf will be used..."
in any event, that is also rendered as bold in a terminal window, so
i'm assuming that, in other environments, there will be a difference
in rendering.
next, WRT options, i notice that some man pages use the word
"option" while others use the word "flag". from the same markdown file
we're using so far, we have both examples:
"Add a line to /etc/hosts. The format is hostname:ip. The
**--add-host** option can be set multiple times."
"To modify the proportion from the default of 1024, use the
**--cpu-shares** flag to set the weighting to 2 or higher."
is it worth bouncing back and forth between "flag" and "option"?
finally, in other pages, there is the occasional example of a flag
that doesn't include the leading two hyphens, such as near the
beginning of podman-save.1.md:
"**podman save** writes to STDOUT by default and can be redirected to
a file using the **output** flag. The **quiet** flag suppresses the
output when set."
i'm guessing that the above should read **--output** and
**--quiet**, no?
in any event, is there a short list of standards for all of this?
rday
4 years, 3 months
Workaround: Re-run not working on failed Cirrus-CI checks
by Chris Evich
All,
Just a heads up: Re-runs ARE working, just not reporting that fact back
through github. For now, if you need to re-run something, do it by:
1. Scroll to the bottom of the failed item in the checks tab on the PR
2. Click the 'View more details on Cirrus CI' link
3. Use the re-run button on that page, it should work/respond fairly
quickly with a new run.
I've contacted Cirrus-CI support about this and made them aware. No
good guess on an ETA or if it's even their problem (it could be a github
issue).
--
Chris Evich, RHCA III
Senior Quality Assurance Engineer
If it ain't broke, yain't tryin' hard nough.
4 years, 3 months
how does .dockerignore interact with podman?
by Robert P. J. Day
almost certainly a dumb question, but i'm unclear on how
.dockerignore interacts with podman in the sense of not passing
certain objects as part of the "build context."
with docker, entries in .dockerignore are explicitly not added to
the context passed to the daemon, so any attempt to, say, COPY or ADD
ignored entries in the Dockerfile are doomed to failure. i tested this
first with docker (on ubuntu) by copying /etc/{passwd,group} to a
build directory, with a Dockerfile that did:
COPY passwd group /
and that worked fine. when i added in .dockerignore the single line
passwd
predictably, the COPY failed not being able to find passwd. so far, so
good.
when i tried the same on fedora 31 with podman 1.6.2, the COPY
worked fine. my early assumption was that podman would ignore
.dockerignore since there is no daemon to which to send the bundled
context, but i've also read elsewhere that podman does *something*
with .dockerignore, although i'm not sure what. and "man podman-build"
makes no mention of .dockerignore.
thoughts?
rday
4 years, 3 months
using asterisks in man page markdown tables causes problems
by Robert P. J. Day
just noticed in current master of libpod a couple man pages that
render badly because (apparently) the markdown is incorporating
asterisks in the second column of the table.
the two examples i've noticed are:
1) the first table in "man podman-history"
2) the second table in "man podman-ps"
is it just me, or are these actual markdown errors? (i need to learn
my markdown so i can fix these when i find them.)
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
4 years, 3 months
