Hi @christoph-zededa thanks for this.

For --verbose, there already is a --verbose option on lkt, see this. Is there any reason not to just use that setting?

For --dry, is this supposed to be like --dry-run? Usually I see people use that as the indication of "tell me what you will do without doing it" (like make -n). We actually have one of those for lkt build which reports the yml file it will use, but apparently not for lkt pkg build, so it is quite welcome.

With that in place, help me understand the implementation? Why are there now two distinct build cmds, buildCmd and buildArgCmd? Isn't there just one lkt pkg build, with some options? That should just require more CLI flags on build, rather than another command.

I also am trying to understand why the properties of type Pkg struct need to become public for this to work. If there is a good reason, then no objection, but it does make for a large PR that changes lots of things just because the names of the properties changed. Why is it necessary?

So I want to solve this problem: lf-edge/eve#5190 (comment)

For --verbose, there already is a --verbose option on lkt, see this. Is there any reason not to just use that setting?

I need it programmatically readable.

For --dry, is this supposed to be like --dry-run? Usually I see people use that as the indication of "tell me what you will do without doing it" (like make -n). We actually have one of those for lkt build which reports the yml file it will use, but apparently not for lkt pkg build, so it is quite welcome.

Sure --dry-run sounds better.

With that in place, help me understand the implementation? Why are there now two distinct build cmds, buildCmd and buildArgCmd? Isn't there just one lkt pkg build, with some options? That should just require more CLI flags on build, rather than another command.

How would you want to invoke linuxkit to print the build-args?

I also am trying to understand why the properties of type Pkg struct need to become public for this to work. If there is a good reason, then no objection, but it does make for a large PR that changes lots of things just because the names of the properties changed. Why is it necessary?

Otherwise json.Marshal cannot access the members.

All in all, I see 3 ways to solve the problem (lf-edge/eve#5190 (comment) ):

• --verbose that outputs some json that can be parsed
• add a way to lkt to get the build-args
• add a way to export the newest (in this git HEAD) image into docker and run it

So I want to solve this problem: lf-edge/eve#5190 (comment)

I don't quite get what you are trying to do. Is it the equivalent of lkt pkg show-tag ./foo but instead of looking for the tag, you are looking for lkt pkg show-build-args ./foo, where it resolves all of the build-args?

Or is it more than that?

So I want to solve this problem: lf-edge/eve#5190 (comment)

I don't quite get what you are trying to do. Is it the equivalent of lkt pkg show-tag ./foo but instead of looking for the tag, you are looking for lkt pkg show-build-args ./foo, where it resolves all of the build-args?

Some parts of EVE are not using linuxkit to build containers. F.e. when we want to run the go tests of pillar, we call make test:

build-docker-test:
        make -C ../../ pillar-cache-export-docker-load
        docker build $(DOCKER_ARGS) --build-arg TEST_TOOLS=y $(DOCKER_BUILD_ARGS) -t $(DOCKER_TAG) . --target build

test: build-docker-test
        rm -f results.json
        rm -f results.xml
        touch results.json
        touch results.xml
        docker run --platform linux/$(ZARCH) -w /pillar \
                --mount type=bind,source=./results.json,target=/pillar/results.json \
                --mount type=bind,source=./results.xml,target=/pillar/results.xml \
                --entrypoint /final/opt/gotestsum $(DOCKER_TAG) \
                --jsonfile /pillar/results.json \
                --junitfile /pillar/results.xml \
                --raw-command -- go test -tags kubevirt -coverprofile=coverage.txt -covermode=atomic -race -json \
                ./...
        docker run --platform linux/$(ZARCH) -w /pillar \
                --entrypoint /bin/sh $(DOCKER_TAG) \
                /pillar/build-scripts/fuzz_test.sh

of course docker build $(DOCKER_ARGS) --build-arg TEST_TOOLS=y $(DOCKER_BUILD_ARGS) -t $(DOCKER_TAG) . --target build is missing the build-args that come from linuxkit so it wont work.

I still am not 100% sure. If I read your message correctly (and I am trying to translate it out of "EVE-specific" and into "linuxkit generic"), you are trying to:

1. Build a container image with some special build-args
2. Run the container image

You want to build the container the same way you do when running lkt pkg build, i.e. all of the build-args, but also add some extra ones. Then you can do docker run at will.

Assuming I understand I see a few approaches to this.

One is what you are proposing, which is to have a command variant that outputs, "this is what I would run to build it". Actually, lkt pkg build --dry-run would be identical to make -n, where it would tell you what the docker command would be. To my mind, the best thing would be if it output docker build ..... Just like with make -n, which you can run and then take the output and run yourself, same thing with lkt pkg build --dry-run.

But I think the simplest is just to build it. Why don't you do lkt pkg build, which builds everything, and then load it into docker? There even is an option (which EVE build uses) of lkt pkg build --docker. Then you can do docker run myimage. Is that easier? If it helps, you can override the image name and tag so it gets whatever name you want.

But I think the simplest is just to build it. Why don't you do lkt pkg build, which builds everything, and then load it into docker? There even is an option (which EVE build uses) of lkt pkg build --docker. Then you can do docker run myimage. Is that easier? If it helps, you can override the image name and tag so it gets whatever name you want.

I prefer the latter method, too.
lkt pkg build does not support to specify a target, does it?
Like --target build in
docker build $(DOCKER_ARGS) --build-arg TEST_TOOLS=y $(DOCKER_BUILD_ARGS) -t $(DOCKER_TAG) . --target build.

How would it look like?
docker run -it $(lkt pkg build --docker pkg/pillar)) go test?

lkt pkg build does not support to specify a target, does it?

As in multistage builds? No, I don't think so. That doesn't quite fit with the linuxkit model. But you could control it with build-args and have a separate build.yml that has different build args.

But you could control it with build-args and have a separate build.yml that has different build args.

That's a bit cumbersome, isn't there an easier way?

That's a bit cumbersome, isn't there an easier way?

I don't find it so (but personal opinions and all that). The linuxkit philosophy is built around the assumption that it is almost completely reproducible. That means things like build args are stored on disk, hence multiple build.yml if you want to change them. EVE itself does this in a few locations: nvidia, fw, pillar.

I don't object per se to having an option that says, "hey linuxkit, tell me what command you would run if I did lkt pkg build with these args and files", i.e. --dry-run or like make -n, and I also don't object to having a machine-readable option (although I have done things like parse docker commands for the purposes of testing things; it works, if a bit odd, and I probably could share the code if it helps).

But for your issue, where you actually are trying to do use what linuxkit pkg build does, but modify it slightly, and then run it, lkt pkg build --build-yml some-other.yml --docker followed by docker run looks like the simplest solution.

I did something of a dry-run implementation, more as a proof of concept, in #4163; maybe try that branch and see what you think?

Pay close attention to the comment on that issue; it doesn't exactly replicate the build process for reasons listed.

The linuxkit philosophy is built around the assumption that it is almost completely reproducible.

Okay, let me try to trick you. What about:

1. Add build-target to build.yaml
2. Add a parameter to linuxkit tool to overwrite values of the build.yaml via a command line parameter.

No? (2) goes to far? What about allowing build.yaml to include another build.yaml then?

trick you

you are not allowed to have that much fun!

Add build-target to build.yaml

For multistage builds? I can see that. I cannot see why it might violate the philosophy. I would want to think it through a bit, but I think it would be fine. It is a bit strange, in that this always is the whole thing, but I can see it work.

Add a parameter to linuxkit tool to overwrite values of the build.yaml via a command line parameter

For some of them, yes; for others, no.

For those that do not change the reproducibility of the build - like the name of the org, or repo, or tag - that already exists. For others like build args or config, I think I would get pushback on it (justifiably).

The list of build.yml config is here

Closing this PR as for now #4163 is good enough.