This change refactors the build loop a bit to make cache optimization easier in the future. Some notable changes:
The special casing around volume snapshots is removed. Every volume is added to the snapshotFiles list for every command that will snapshot anyway.
Snapshot saving was extracted to a sub-function
The decision on whether or not to snapshot was extracted
* Rework cache key generation a bit.
Cache keys are now based on the previous commands, rather than the previous state
of the filesystem.
* Refactor command interface a bit, only cache the context for commands that use it.
I merged a contributor's PR which modifed the HasFilepathPrefix function
to take an additional argument, but the PR hadn't been rebased. One of the
liting tests in Travis caught this bug.
As described in #373, kaniko panics when provided with --cache and --no-push since it tries to infer a cache repo from the destination, which doesn't exist.
To fix this, I added a check to make sure --cache-repo is passed in when both these flags are provided.
In the debug image, declare /busybox as a volume so that it is automatically whitelisted, because we don't want to delete it when building multi-stages images.
FYI this is required when using Jenkins, because we need to use the debug kaniko image to be able to start the container "doing nothing" (with /busybox/cat) before building (by executing /kaniko/executor directly inside the container)
See https://issues.jenkins-ci.org/browse/JENKINS-52576
Currently, kaniko can only build a single image per container run, because the filesystem is full of the content of the first image.
When running kaniko in Jenkins, where we need to start the container "doing nothing" first (using the debug kaniko container), and then exec /kaniko/executor, this is a limitation because it means that if we want to build multiple images, we need to start multiple containers - see https://groups.google.com/forum/#!topic/kaniko-users/_7LivHdMdy0 for more details
A solution to fix this issue is to add a new flag to cleanup the filesystem at the end - the same way it is done between stages when building a multi-stages image. This way, the same (debug) container can be used to build multiple images.
* set default HOME env properly
* set HOME to / if user is set by uid
* fix test
* continue to skip user_run test
* fix unit test to match new functionality
* Enable overwriting of links (solves #351)
* add integration test to check extraction of images with replaced hardlinks
* Prevent following symlinks during extracting normal files
This fixes#359, #361, #362.
When running container-diff in integration tests, both stdout and stderr were being returned
and unmarshalled into the container-diff json object. If container-diff
was giving any error messages (such as, if it didn't have permissions to
extract a file), this would fail even if ultimately no
differences between the filesystems existed.
I updated the RunCommands to only return stdout and print stderr if the
command fails.
I changed RunE to Run so that usage wouldn't show upon error. Usage will
still show if PersistentPreRunE fails, which makes sense since those
functions check to make sure arguments passed in are valid.
Also changed logging of multi arg flags to Debugf so that output would
be cleaner.
peter-evans
priyawadhwa
Ian Beringer
dlorenc
Kartik Verma
Nao YONASHIRO
Benjamin Nørgaard
Jason Hall
Vincent Behar
Sharif Elgamal
xanonid