However for identification using automated tooling (skaffold with custom builds), I require:
./result/caddy
./result/web2ldap
Questions:
How can I work around it?
Where can I put the lever to provide a PR so this becomes the default?
Thanks for your help! dockerTools is really awesome, I can’t wait to start making upstream PRs to some k8s repos I care.
EDIT: I’m using tempfiles as result for skaffold now, and the linkFarm approach for produceing a nice (and git ignorable) folder hierarchy for manual builds.
There might be more elegant ways to do this, but this is a way:
pkgs.linkFarm "my-output" ( # 4
pkgs.lib.attrsets.mapAttrsToList # 2
(name: path: { inherit name path; }) # 3
{ # 1
one = pkgs.dockerTools.buildLayeredImage {
name = "hello";
contents = [ pkgs.hello ];
};
two = pkgs.dockerTools.buildLayeredImage {
name = "other";
contents = [ pkgs.busybox ];
};
}
)
$ ll result/
total 8
lrwxrwxrwx 2 root root 69 Dec 31 1969 one -> /nix/store/9174vfz18j45ashyigfh465fl0nr0hr7-docker-image-hello.tar.gz
lrwxrwxrwx 2 root root 69 Dec 31 1969 two -> /nix/store/qjxwvh5018lsh8d3c47ih1v6axlhr7zq-docker-image-other.tar.gz
EDIT: Some more details:
At (1) is the input, a bog standard attribute set, with the keys being the intended name as symlinked, and the value being any result, here it’s dockerTools uses.
At (2) we are using lib.attrsets.mapAttrsToList, with a function at (3) that shapes it into a form that linkFarm can use. I’m using kind of a dirty trick with inherits, which I can do since I named the arguments as I wanted them to be.
And well, (4) is the call to linkFarm, where I give it the name of the output (store path), and the result of mapAttrsToList.
Pretty cool! For (even) better understanding, the name of the link farm is the folder itself, so I renamed it to “result-folder”.
$ ls result
result ⇒ /nix/store/mf1sbgp8fwldjwws4w3lg992y7bsn027-result-folder
$ ls result/
caddy ⇒ /nix/store/q2kia1jsgxgrnavv3djshjskx80hf0ix-docker-image-caddy.tar.gz
web2ldap ⇒ /nix/store/ijk9q6cvyqcwp6yazq4c3p5zq99i1a30-docker-image-web2ldap.tar.gz
This is not something in dockerTools can change. The naming is handled in Nix itself so any change would need to go there.
One idea I have is that you can have the build script instead depend on the output like ${images.caddy}, which does not need to rely on the result symlink. I’m not sure if this actually applies in your case, because I’m not familiar with skaffold and how a directory is required.
The skaffold custom nix-builder script might be a candidate for upstreaming, not sure where exactly, though. Any precise pointer? - as part of the skaffold package?
No real ideas from me, I haven’t heard of anything in that first paragraph (not that that means anything of course!)
As for skaffold, I peeked, I was wondering about native Nix integration as well. If nothing else it might be neat for Nix visibility (I’m separately thinking of other Nix/CI integration points). I couldn’t tell if being a native integration actually got you more features than being a custom docker-based builder.
skaffold would trivially use buildkit, if told so. So does kaniko as only option - which is used by a lot of current CIs do do in-cluster image creation (wether that’s a good thing…).