#looking into the `Dockerfile` thing now
south cove
no rush, thanks for looking into this at all.
glacial ore
@south cove if you run dagger do build twice does it run the tests each time?
glacial ore
south cove
the tests are not coupled to build. If you just run build, no tests are run
south cove
yes, I cleared the cache before generting the output there
glacial ore
.
├── Dockerfile
├── go.mod
├── go.sum
├── hello.cue
├── main.go
└── main_test.go
0 directories, 6 files```FROM golang:1.19 as deps
RUN mkdir /app
WORKDIR /app
COPY . /app
RUN go get ./...```package main
import (
"dagger.io/dagger"
"dagger.io/dagger/core"
"universe.dagger.io/docker"
)
dagger.#Plan & {
actions: {
src: core.#Source & {
path: "./"
exclude: ["hello.cue"]
}
test: {
deps: docker.#Dockerfile & {
source: src.output
target: "deps"
}
vet: docker.#Run & {
input: deps.output
command: {
name: "go"
args: ["vet", "./..."]
}
}
test: docker.#Run & {
input: deps.output
command: {
name: "go"
args: ["test", "./..."]
}
}
}
build: docker.#Dockerfile & {
source: src.output
}
}
}```that's pretty much it Nico. Do you see anything different?
south cove
your docker file isnt multi staging
glacial ore
shouldn't affect. Let me change it to be multi-staging
south cove
mine looks like this
FROM golang:1.19-alpine as deps
ENV CGO_ENABLED=0
WORKDIR /go/src/
COPY go.mod go.sum ./
RUN go mod download
COPY . .
FROM deps as builder
RUN go build -ldflags '-w -s' -v -o /usr/local/bin/function ./
FROM busybox as final
COPY --from=0 /etc/ssl/certs /etc/ssl/certs
COPY --from=builder /usr/local/bin/function /usr/local/bin/function
COPY --chmod=755 entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh", "function"]
then I clear the dagger cache by removing volume and container. Then I run one time test and one time build
and build is pulling the go dependencies again
glacial ore
then I clear the dagger cache by removing volume and container. Then I run one t...
yep, also ddid this
ok, managed to repro. I didn't notice that build was actually the same Dockerfile
interesting.. I need @bright breach advise here
bright breach
interesting.. I need <@949034677610643507> advise here
(appending to queue, I'll take a look in a little bit)
glacial ore
@bright breach in that tar file if you run dagger do test and then dagger do build with a fresh cache you'll notice that the second cmd doesn't re-use cache when I think it should
glacial ore
my guess is that probably something related to how our Dockerfile action generates the llb opts
bright breach
<@949034677610643507> in that `tar` file if you run `dagger do test` and then `d...
Pulled that down, cleared out dagger-buildkitd, ran dagger do test and then dagger do build and on the second run all of the steps in deps were cached for me. Is that different than what you all are seeing?
glacial ore
Not what I was seeing. When I ran the build action I saw that the deps step wasn't cached
🤔
I'm AFK now. I'll share a gif video later
glacial ore
@bright breach you're correct I was seeing the output incorrectly
@south cove if you check your build output here https://dagger.cloud/runs/f171688f-d6d3-4e84-8e45-923ee3c40892 you can see that the go mod download step is indeed cached (image1). The reason why you're seeing some deps output in the logs (image2) is because go build is probably computing some missing stuff that wasn't computed from go mod download
apologies for the noise Erik 🙏
bright breach
apologies for the noise Erik 🙏
No worries! Happy to be a second pair of eyes