If we don't want to have separate registry tags by architecture (EWWWW),
we need to be able to build multiarch docker images. This is pretty
simple, and just requires making a manifest pointing to each of the
component images.
I was *going* to just do this API prodding with manifest-tool, but it
doesn't support putting metadata on the outer manifest, which is
actually kind of a problem because it then doesn't render the metadata
on github. So I guess we get a simple little containers API
implementation that is 90% auth code.
Change-Id: I8bdd118d4cbc13b23224f2fb174b232432686bea
I have checked the image can build things and inspected `diff -ru`
compared to the old image. As far as I can tell it is more or less
the same besides the later git change.
Layers are now 65MB or less, and we aren't against the maxLayers limit
for the broken automatic layering to do anything but shove one store
path in a layer (which is good behaviour, actually).
This uses nix2container which streams images, so the build time is much
shorter.
I have also taken the opportunity to, in addition to fixing the 400MB
single layer (terrible, and what motivated this in the first place),
delete about 200MB of closure size inflicted by git vs gitMinimal
causing both perl and python to get into closure.
People mostly use this thing for CI, so I don't really think you need
advanced git operations, and large git can be added at the user side if
really motivated.
With love for whichever container developer somewhat ironically assumed
that one would not run skopeo in a minimal container that doesn't have a
/var/tmp.
Fixes: lix-project/lix#378
Change-Id: Icc3aa20e64446276716fbbb87535fd5b50628010
When leveraging remote builders or cache in CI workloads, sometimes you need to configure nix to connect via SSH to a remote server.
It is the case for example when using nixbuild.net.
By including `openssh` package, CI should be able to reach remote builders when configured i.e. with environment variables.
nix profile will otherwise throw this error:
error: path '/nix/var/nix/profiles/default/manifest.nix' is not in the Nix store
That's not entirely true since manifest.nix is within a directory in
the nix store but nix profile seems to require the manifest.nix itself
to be a store path.
1. `target` is the wrong name, that is just for compilers per out
standard terminology. We just need to worry about "build" and "host".
2. We only need one `pkgs`. `pkgs.buildPackages` is how we get anything
we need at build time.
3. `crossSystem` is the name of a nixpkgs parameter that is actually an
attribute set, not a 2-part "cpu-os" string.
3. `pkgsCross` effectively evaluates Nixpkgs twice, which is
inefficient. It is just there for people poking around the CLI / REPL
(and I am skeptical even that is a good idea), and *not* what written
code should use, especially code that is merely parametric in the package set
it is given.
4. We don't need to memoize Nixpkgs here because we are only doing one
pkg set at a time (no `genAttrs`) so it's better to just delete all this
stuff. `flake.nix` instead would do something like that, with
`genAttrs` (though without `pkgsCross`), if and when we have hydra jobs
for cross builds.
jade
Rebecca Turner
Markus Wamser
