| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |\
| |
| | |
dockerTools: test pullImage
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
https://www.gnu.org/software/tar/manual/html_node/files.html
files starting with - can be treated as command line options, which isn't desirable here
|
| |
|
|
|
| |
This provides a /usr/bin/env, for shell scripts using the
"/usr/bin/env executable" shebang.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, a non-existent nsswitch.conf causes a very misleading host
resolution, differing from the defaults people are used to.
According to
https://github.com/golang/go/issues/22846#issuecomment-346377144, glibc
says the default is "dns [!UNAVAIL=return] files".
This means, `/etc/hosts` isn't really honored, causing all sorts of
unexpected behaviour.
Let's prevent this, and first ask `/etc/hosts` before querying DNS, like
we do on NixOS too.
|
| |
|
|
| |
This has been synonymous for ~5y.
|
| |
|
|
|
|
|
|
| |
skopeo 1.4.x doesn't accept --src-tls-verify as a flag to the *program*,
only as a flag to copy; we must pass it after the "copy" verb, or it
will fail with:
> FATA[0000] unknown flag: --src-tls-verify
|
| | |
|
| |\
| |
| | |
tarsum: init
|
| | |
| |
| |
| |
| | |
- move from dockerTools.tarsum
- remove go from runtime closure
|
| |/
|
|
| |
Indeed Docker can not run darwin exes, but darwin can build
Docker images, as some users already do with buildLayeredImage.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skopeo will disable the progress bar if it detects that stdout isn't a
TTY - in order to make it think that stdout _isn't_ a TTY and therefore
avoid it printing a lot of "…" on separate lines, we pipe the output
through cat.
This changes the output from:
…
…
…
…
…
…
to the eminently more useful and less spammy:
Getting image source signatures
Copying blob sha256:[snip]
Copying blob sha256:[snip]
Copying blob sha256:[snip]
Copying config sha256:[snip]
Writing manifest to image destination
Storing signatures
|
| |\
| |
| | |
nixosTests.docker-tools: Fix nixFromDockerHub example sha
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For https://github.com/NixOS/nixpkgs/pull/125211 I tried to test
the fetcher with
nix-build -A dockerTools.examples.nixFromDockerHub --option substitute false
But it failed. I haven't figured out the cause, but the outputs
match, so it's probably the hashing method (flat/recursive) that
changed at some point. (The names did match.)
|
| |\ \
| |/
|/| |
dockerTools: Fix passthru image tag
|
| | |
| |
| |
| |
| |
| | |
It should match the actual image tag.
This fixes the problem introduced in 00996b5e03f33bebafc2b17c41a175d3726a9bde
https://github.com/NixOS/nixpkgs/pull/115491#pullrequestreview-672789901
|
| |\ \
| |/
|/| |
build-support/docker: pass tlsVerify to support http registries
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Adds includeStorePaths, allowing the omission of the store paths.
You generally want to leave it on, but tooling may disable this
to insert the store paths more efficiently via other means, such
as bind mounting the host store.
|
| |/ |
|
| |\
| |
| | |
dockerTools: Implement merging of image tarballs
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `docker load` command supports loading tarballs that contain
multiple docker images with their respective image names and tags. This
enables distributing these images as a single file which simplifies the
release of software when an application requires multiple services to
run.
However, pkgs.dockerTools only create tarballs with a single docker
image and there exists is no mechanism in nixpkgs to combine the created
tarballs. This commit implements merging of tarballs in a way that is
compatible with `docker load`.
|
| |\ \
| |/
|/| |
dockerTools: fix absent /proc during runAsRoot
|
| | |
| |
| |
| |
| |
| | |
The chroot environment under mnt had /dev and /sys via bind mounts,
but nothing setting up /proc. The `--mount-proc` argument to unshare
defaults to /proc, which is outside of the chroot envirnoment.
|
| |\ \
| | |
| | | |
dockerTools.streamLayeredImage: add fakeRootCommands option
|
| | | | |
|
| | | |
| | |
| | |
| | | |
fakeRootCommands
|
| | | |
| | |
| | | |
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For images running on Kubernetes, there is no guarantee on how duplicate
environment variables in the image config will be handled. This seems
to be different from Docker, where the last environment variable value
is consistently selected.
The current code for `streamLayeredImage` was exploiting that assumption
to easily propagate environment variables from the base image, leaving
duplicates unchecked. It should rather resolve these duplicates to
ensure consistent behavior on Docker and Kubernetes.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is now possible to pass a `fromImage` to `buildLayeredImage` and
`streamLayeredImage`, similar to what `buildImage` currently supports.
This will prepend the layers of the given base image to the resulting
image, while ensuring that at most `maxLayers` are used. It will also
ensure that environment variables from the base image are propagated
to the final image.
|
| |\ \
| | |
| | |
| | |
| | | |
lbpdt/feature/docker-tools-layered-image-name-slashes
dockerTools.buildLayeredImage: image names with registry/ prefix
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When using `buildLayeredImage`, it is not possible to specify an image
name of the form `<registry>/my/image`, although it is a valid name.
This is due to derivations under `buildLayeredImage` using that image
name as their derivation name, but slashes are not permitted in that
context.
A while ago, #13099 fixed that exact same problem in `buildImage` by
using `baseNameOf name` in derivation names instead of `name`. This
change does the same thing for `buildLayeredImage`.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`stream_layered_image.py` currently assumes that the store root will be
at `/nix/store`, although the user might have configured this
differently. This makes `buildLayeredImage` unusable with stores having
a different root, as they will fail an assertion in the python script.
This change updates that assertion to use `builtins.storeDir` as the
source of truth about where the store lives, instead of assuming
`/nix/store`.
|
| | |
| |
| |
| | |
Closes #115455
|
| |\ \
| | |
| | | |
dockerTools: fix build on Darwin
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Fixes #110665
Introduced by #109420
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Italian.
|
| | | |
|