#Weird cache invalidation behaviour when using `_EXPERIMENTAL_DAGGER_RUNNER_HOST`

1 messages · Page 1 of 1 (latest)

late flare
#

Hi, I've been building a fairly complex CI pipeline using Dagger. Long story short: the CI itself likes to rebuild things every time, even stuff that hasn't changed. One example: we build from source a dependency, fetched from a remote Git repository, by commit. The source is not changing, nor the "instructions" how to build it. We're using the Go SDK.

The observed behaviour is as follows:

  1. dagger call works correctly locally all the time, returning CACHED. It's not affected by any non-functional change to the pipeline. Testing on macOS, and the Dagger Engine runs in colima.
  2. The same dagger call, but with _EXPERIMENTAL_DAGGER_RUNNER_HOST also returns cached, as long as the dagger pipeline is not touched. As soon as e.g. a comment is introduced in the source, the pipeline rebuilds
  3. The dagger call from the CI runner always rebuilds (I guess it falls in the same category as point two).

The CI runner is based on Forgejo Actions (similar to GitHub actions). It obviously clones a fresh copy of the repository.

Is there a list of things I could check that could trigger the invalidation? It's hard to pinpoint a problem in our pipeline, as the behaviour differs across runners.

Thanks!

open echo
late flare
#

on it!

open echo
#

it's expected that when you change anything in the module source code, for the module to get regenerated. Having said that, it shouldn't invalidate all the cache since all the subsequent dag.X calls that your module chain does, should be cached as long as their inputs haven't changed

late flare
#

I do have some issues getting dagger.cloud working at the moment. I got this in the console:

failed to fetch org: input: org.moduleIgnorePatterns unauthorized
input: org.moduleIgnorePatterns unauthorized

tried disabling adblockers, changing browser (pristine chromium).

open echo
quartz gull
#

Could you do a quick hard refresh? @late flare

#

Sometimes our auto-update mechanism doesn't work as expected and UI/API rollouts are not sync'ed correctly. We are improving this and it shouldn't be necessary for a user to hard-refresh

late flare
#

Tried... as said also over multiple browsers 🙂 no difference

quartz gull
#

My bad. I missread the error message. Taking a look now

quartz gull
#

@late flare could you give it another shot and let me know if it works for you now?

late flare
#

yep seems like it's back on track 😉

quartz gull
#

Awesome, thanks for confirming and sorry for the trouble 🙏

quartz gull
#

@late flare could you share the name of the organization you are using in dagger cloud?

late flare
#

I think I managed to find the root cause. The engine had a DAGGER_CLOUD_URL set to some semi-random value. Once removed, the cache stopped being invalidated.

#

How about secret values @quartz gull ? It seems that steps that depend on a secret environment variable are never cached. Could that be?

open echo
#

@late flare if you could share with us your Cloud org name that'd be much appreciated so we can test that the issue you had last week has been finally fixed 🙏

late flare
#

I am not sure how that can help you: while trying to unblock myself I created an organization called testing-invalidation, but that was also not working,

open echo
#

just to double check, Cloud is working for you now, isn't it?