Support user-supplied Docker image archive derivations#92
Support user-supplied Docker image archive derivations#92tomeon wants to merge 4 commits intohercules-ci:mainfrom
Conversation
|
Thank you!
I try to avoid abbreviations where possible, but a different name may be needed.
I agree with your analysis.
Yes. The module system comes with an overriding feature that you probably already know from |
|
bors try |
tryBuild failed |
|
Thank you for the feedback, @roberth! I will make the changes you highlighted, hopefully within the next few days. In the meantime, I took a look at the build failures, and they appear to be due to an OOM condition that occurs before I suspect that this is a latent issue exposed by the changes I made to the test suite; will bisect to be sure. |
tomeon
force-pushed
the
arbitrary-image-drv-support
branch
2 times, most recently
from
ad24d09 to
457b92c
Compare
tomeon
changed the title
tomeon
force-pushed
the
arbitrary-image-drv-support
branch
2 times, most recently
from
9136a62 to
358a2e4
Compare
And a mere ~1350 days later, I'm back with some updates (~1350 is a "few days" by geological or cosmological standards, I suppose...). IIRC the test failure was due to the I've updated the PR as follows:
|
Via the `services.<name>.image.tarball` option. This permits users to supply any valid image archive, potentially (but not necessarily) generated by a builder function from `pkgs.dockerTools`.
and associated subtest. This tests the functionality of the newly-added `services.<name>.image.tarball` parameter.
and replace its uses with `image.tarball{,.imageName,.imageTag}`.
This changeset is a hard deprecation of `build.image{,Name,Tag}` and
does not do any option renaming, etc., as the removed options were all
marked as internal.
This changeset also includes code that ensures the newly-relied-upon
options are properly defined, raising user-visible assertion errors if
no sane default image name or tag could be inferred.
tomeon
force-pushed
the
arbitrary-image-drv-support
branch
from
358a2e4 to
a891633
Compare
|
Can this be merged?
If there's some work left I could also contribute |
3 participants
First of all, thank you for this fantastic utility! I am so pleased to be able to describe Docker Compose environments using Nix instead of YAML :)
This PR introduces support for user-supplied Docker image archives via the attribute
service.<name>.image.drv. The idea is that users can invokedockerTools.buildImage,dockerTools.buildLayeredImage, or any other means of constructing a derivation that evaluates to a Docker image archive, then hand this off to Arion for use in the Compose environment.This permits Arion users to exercise fine-grained control over their Docker images, even finer than what is possible with
service.<name>.image.rawConfig. Additionally, it makes it easier to manipulate images separately from Arion (e.g.,docker loading an archive constructed with adockerToolsfunction, thendocker pushing it to some registry).I am a Nix neophyte, and anticipate that I've committed any number of misjudgments here. Some questions that spring to mind:
service.<name>.image.drva good name? Maybe there's something more descriptive/straightforward?service.<name>.image.drvaccepts eithernullor any derivation whatever, regardless of whether it evaluates to a Docker image archive when built. This seems fine for an option markedinternal, but maybe not one intended for public consumption. Checking for the AFAIK-dockerTools-specificimageNameorpassthru.imageTagis probably too stringent; maybe there are sentinels of Docker imagehood not specific todockerTools? OTOH maybedocker load-time errors are acceptable here, as they are basically analogous to the runtime errors that would occur upon mis-specifyingservice.<name>.service.name?build.image = config.image.drv or builtImage? It does not feel DRY to have bothbuild.imageandimage.drv, but I couldn't find a straightforward way to remove the duplication. In particular, the following construct:led to the error:
I've also included a fix for an issue in the
nixosTestsuite: theworkdirectory containingarion-pkgs.nixandarion-compose.nixwasn't being properly cleaned up, leading to all test cases subsequent to the first (minimal) failing to run (more precisely, all test cases subsequent to the first simply re-ran the first).Happy to put this changeset in a separate PR if you'd prefer.
Thanks in advance for your consideration!