Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docker-slim: init at 1.26.1 #75564

Closed
wants to merge 1 commit into from
Closed

docker-slim: init at 1.26.1 #75564

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 29 additions & 0 deletions pkgs/tools/misc/docker-slim/default.nix
View file
Open in desktop
@@ -0,0 +1,29 @@
{ buildGoModule, fetchFromGitHub, stdenv, docker }:

buildGoModule rec {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use buildGoPackage, because upstream vendorizes its dependencies

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, thanks. Can you please tell me how to recognize that myself so I can be better in the future?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, thanks. Can you please tell me how to recognize that myself so I can be better in the future?

If upstream has its dependencies in a vendor/ directory, it's fine to use buildGoPackage, if go.mod is used, buildGoModule can be used :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the delay

Can you please tell me how to recognize that myself so I can be better in the future?

The main difference between both, is that buildGoModule abuses fixed-output derivations which may not be preferable; because introduces impurities, such as network access NixOS/nix#2270

As @Ma27 mentioned, we should buildGoPackage when a package vendorizes its dependencies (vendor/ directory), since it's a regular expression and we don’t have to maintain a deps.nix
In the rest of the cases, the maintainer can choose which function to use

pname = "docker-slim";
version = "1.26.1";

goPackagePath = "github.com/docker-slim/docker-slim";
src = fetchFromGitHub {
owner = "docker-slim";
repo = pname;
rev = version;
sha256 = "01bjb14z7yblm7qdqrx1j2pw5x5da7a6np4rkzay931gly739gbh";
};

subPackages = [ "cmd/docker-slim" "cmd/docker-slim-sensor" ];

modSha256 = "05sayqbr65x98bx61ma6xnkvcsbr9g1lsviazc4szzqdizfck8yr";

meta = with stdenv.lib; {
description = "Minify and secure Docker containers";
homepage = "https://github.com/docker-slim/docker-slim";
license = licenses.asl20;
maintainers = with maintainers; [ filalex77 ];
platforms = docker.meta.platforms;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, does it depend on docker?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes images by name, so I assume it asks Docker for them.

# internal/app/sensor/monitors/ptrace/monitor.go:151:16: undefined: system.CallNumber
# internal/app/sensor/monitors/ptrace/monitor.go:161:15: undefined: system.CallReturnValue
badPlatforms = [ "aarch64-linux" ];
};
}
2 changes: 2 additions & 0 deletions pkgs/top-level/all-packages.nix
View file
Open in desktop
Expand Up @@ -201,6 +201,8 @@ in

docker-ls = callPackage ../tools/misc/docker-ls { };

docker-slim = callPackage ../tools/misc/docker-slim { };

docker-sync = callPackage ../tools/misc/docker-sync { };

docui = callPackage ../tools/misc/docui { };
Expand Down