Summary
The user is seeking assistance with a Golang application that has private dependencies and is encountering issues with caching the RUN --ssh
command while using Earthly in GitHub Actions. They describe a target script for SSH setup and dependency downloading, utilizing the --ci
argument and various caching methods. The user notes that the setup works well on their MacBook and in their self-hosted Jenkins CI, but they are confused about the caching of SSH commands in GitHub Actions.
zenyui
i’m sure someone has asked this, so apologies in advance, but I can’t find another thread/doc about it
I’m trying to build a golang app with private dependencies, and I can’t seem to get earthly to cache the RUN --ssh
command below… are ssh commands cached?
Here’s the target:
# add git to known hosts
RUN mkdir -p /root/.ssh && \
chmod 700 /root/.ssh && \
ssh-keyscan <http://github.com|github.com> >> /root/.ssh/known_hosts
RUN git config --global url."git@github.com:".insteadOf "<https://github.com/>"
WORKDIR /app
# download deps
COPY go.mod go.sum ./
RUN --ssh go mod download -x```
Notes:
• I’m invoking the build with the `--ci` arg
• i’ve tried I’ve tried explicitly pushing the `deps` target as an image tag
• also tried using `--save-inline-cache --use-inline-cache` args
zenyui
interesting
rrjjvv
Good luck!
zenyui
i’ll let you know what i find
zenyui
appreciate the input!
zenyui
maybe it’s the cache size default on the github actions runner, i’ll give that a shot
rrjjvv
Now, that's running local. And I can vouch that it runs identically in my CI (which is self-hosted Jenkins). I don't have any experience with github tooling (outside of core git).
zenyui
i’m just experiencing this issue in github actions / ghcr
zenyui
so locally on my macbook it does cache
rrjjvv
Trimmed/redacted snippet from one of my projects:
$ earthly +build
<snip>
+go-base | *cached* --> RUN git config --global url."<ssh://git@git.mycorp.com:7999/>".insteadOf "<https://git.mycorp.com/scm/>"
<snip>
g/p/e/git+bitbucket-host-keys | *cached* --> RUN echo "$_BB_PROD" > ssh_known_hosts
+go-base | *cached* --> COPY +bitbucket-host-keys/ssh_known_hosts /etc/ssh/ssh_known_hosts
<snip>
+build-base | *cached* --> COPY go.mod go.sum ./
+build-base | *cached* --> RUN --ssh go mod download && go mod verify && go install <http://github.com/jmattheis/goverter/cmd/goverter@latest|github.com/jmattheis/goverter/cmd/goverter@latest> && go install <http://github.com/kazhuravlev/options-gen/cmd/options-gen@latest|github.com/kazhuravlev/options-gen/cmd/options-gen@latest>
+build-base | *cached* --> COPY *.go .
+build-base | --> COPY --dir internal/ .
+build | --> mkdir /run
+build | --> IF [ "$race" -eq 1 ]
+build | --> RUN go generate ./... && go vet ./... && go build $go_args $go_build_tags -o app && go test $go_args $go_build_tags ./...
+build | ? <http://git.mycorp.com/pipe/static-file-publisher|git.mycorp.com/pipe/static-file-publisher> [no test files]
+build | ok <http://git.mycorp.com/pipe/static-file-publisher/internal|git.mycorp.com/pipe/static-file-publisher/internal> 0.008s```
I made a trivial change to a source file, and you can see the `RUN --ssh` was cached. (There are open bug tickets where the "cached" indicator is incorrectly applied, but I can assure you it's indeed cached.)
zenyui
for more context, i’m pushing to github’s ghcr and running in github actions
zenyui
and yes, the inline cache args were an attempt to get regular, layer-based caching working
zenyui
i’m not currently using the cache mount feature
zenyui
i’m having issues with the inline layer-based caching
rrjjvv
> are ssh commands cached?
Yes, with the same caveats as any other RUN
commands. I'm a user of private dependencies as well (both go and python's equivalent) and caching works just fine. However, based on your last bullet, you may want to elaborate on exactly which kind of caching you're having issues with. I personally don't use those explicit/shared/remote caches (i.e., those flags in your last bullet point). It's not clear if those were attempts to get 'regular' caching working, or if that's actually your end goal.
I think when most folks talk about (unqualified) caching, it's usually about 'standard' layer-based buildkit caching. That has always worked just fine for me. I can always speak to CACHE
in combination with RUN --ssh
; that has always worked fine for me as well (with some caveats). I can't speak to the registry-based caching.
If you are referring to 'regular' caching, you may be running into the same issues that would affect any usage of RUN
: inadequate cache size, global ARG
values that are changing, etc.