#Hey guys. Having some more host file

1 messages · Page 1 of 1 (latest)

subtle holly
#

Can you share some details, best in the form of traces where it's happening? I think it's most productive to be able to review those first. It's possible they may be all we need and if not we'll at least be better prepared to debug w/ you further 🙂

tacit gull
#

yeah sure thing happy to share traces might DM them to you

#

To summarise the issue I am facing.

The repo is our dagger modules mono repo. I am now checking in all the generated code into this repo and then as part of a PR check we run go test ./... over each module in the mono repo.

#

As you can see from the trace DMed to you, we get a strange error that I cannot reproduce by running go test ./... locally over that same module.

#

Looking carefully at the error, it appears that there are package references for a in the internal/dagger/dagger.gen.go file which don't match the currently tested pacakge.

#

You can see that the module being tested is node-build which has the go package string dagger/node-build/internal/dagger however the go test command complains that dagger/kubernetes/internal/querybuilder can't be found.

#

node-build and kubernetes are two modules that live like this in our mono repo:

/
|-- modules
      | -- kubernetes
      | -- node-build
#

both are go modules

#

so if I didn't know any better I would say that the contents of modules/kubernetes/internal/dagger/dagger.gen.go was being swapped with modules/node-build/internal/dagger/dagger.gen.go

#

However, weirdly (as you can see from the trace) I tried to print the contents of that file multiple ways and I can see it is correct :/

#

So I am at a loss lol and very well it could be me doing something stupid

#

Appreciate you looking into this Erik!!! Thank you kindly 🙂

#

I am just going to try one more thing and run it again but print the contents of the file if the go test fails in the same exec call

#

To see if I can see the bad file

subtle holly
#

At a first skim, this looks exactly like https://github.com/dagger/dagger/issues/8031 which is surprisingly an upstream Go issue.

I think it'd be worth a try to see if setting GODEBUG=goindex=0 before any go test or similar commands fixes it.

subtle holly
tacit gull
#

cool will try that

#

Ah look at this

# 
user default: node-build-tests(jfrogToken="env://JFROG_NPM_TOKEN")
user default: node-build-tests(jfrogToken="env://JFROG_NPM_TOKEN")
Error: exit code: 1 [traceparent:df98687a29142cf6b137635ca85089eb-411848ec5f9daaea]
Stdout:
FAIL    dagger/node-build [setup failed]
FAIL    dagger/node-build/internal/dagger [setup failed]
?       dagger/node-build/internal/querybuilder [no test files]
?       dagger/node-build/internal/telemetry    [no test files]
FAIL
// Code generated by dagger. DO NOT EDIT.

package dagger

import (
        "context"
        "encoding/json"
        "errors"
        "fmt"
        "net"
        "net/http"
        "os"
        "reflect"
        "strconv"

        "github.com/Khan/genqlient/graphql"
        "github.com/vektah/gqlparser/v2/gqlerror"
        "go.opentelemetry.io/otel"
        "go.opentelemetry.io/otel/propagation"
        "go.opentelemetry.io/otel/trace"

        "dagger/node-build/internal/querybuilder"
        "dagger/node-build/internal/telemetry"
)

func Tracer() trace.Tracer {
        return otel.Tracer("dagger.io/sdk.go")
}

// reassigned at runtime after the span is initialized
Stderr:
# dagger/node-build
internal/dagger/dagger.gen.go:22:2: package dagger/kubernetes/internal/querybuilder is not in std (/usr/local/go/src/dagger/kubernetes/internal/querybuilder)
# dagger/node-build
internal/dagger/dagger.gen.go:23:2: package dagger/kubernetes/internal/telemetry is not in std (/usr/local/go/src/dagger/kubernetes/internal/telemetry)
# dagger/node-build/internal/dagger
internal/dagger/dagger.gen.go:22:2: package dagger/kubernetes/internal/querybuilder is not in std (/usr/local/go/src/dagger/kubernetes/internal/querybuilder)
# dagger/node-build/internal/dagger
internal/dagger/dagger.gen.go:23:2: package dagger/kubernetes/internal/telemetry is not in std (/usr/local/go/src/dagger/kubernetes/internal/telemetry)
#

I had it output the file that apparently has the bad package references

#

but the file is completely fine

#

will re run again with that env var... looking lik the issue you just flagged

#

okay when I rerun with your flag it magically works now ????

subtle holly
tacit gull
#

Ah okay. Wow!

#

Erik, I really appreciate your time

#

Sorry to bother you with something like this 🙂

#

I am personally relieved it wasn't a dagger bug though

subtle holly
#

No problem at all. I spent a long time extremely confused like you were, so glad I could save the prolonged headache!

tacit gull
#

Because I was pretty sure we stamped out the host caching files

subtle holly
tacit gull
#

Have a nice evening

subtle holly
#

you too!

scarlet sierra
#

Hey, I was doing some digging today and wanted to recap my findings.

The Go cache key is calculated using these inputs:

  1. Module Root Path
  2. Go Version
  3. Index Version
  4. Package Directory Path
  5. File Metadata (Name, Modification Time, Size)

Since the Go and Index versions are constant, and we loop through modules mounting them all to /go/src/, #1 through #4 become identical across every container (e.g., /go/src/internal/dagger).

That leaves the file metadata:

  • Filename: Identical (dagger.gen.go).
  • Size: Identical (since the conflicting module names happen to be the same length).
  • Modification Time: I found that files are given a new modification time on a fresh clone, and it is extremely likely that files will have identical timestamps in CI. I suspect GitHub caching had some involvment here.

This is why we started seeing the error after committing the generated code. I tried to see if it was possible to reproduce locally, with a fresh clone, but after testing multiple times I found the timestamps were always slightly different.

Manually updating the timestamp with touch <file> or using a unique path like /go/src/<module-name> both resolved the issue.