#Kyle Zenith first pass
1 messages ยท Page 1 of 1 (latest)
Yeah ill write them up and share them tomorrow. The first challenge was that my ci code is a subdirectory of my project, which is different than the demo and took a minute to figure out how that should work. And i dont have it working yet and Iโm not sure why. More details tomorrow
I have many thoughts on this topic ๐ On hold for now
ok forget tomorrow, I wrote up some notes ๐
https://gist.github.com/kpenfound/7f239dcf18e29f1812531dcf95b02c13
cc @winter sparrow @pallid girder
and now that I have that written down you can also tell me what I've done wrong in my code ๐
This is a "user is always right" situation, there's no "you are holding it wrong" ๐
I think the biggest impediment is like you said that you aren't seeing output about what went wrong. Currently, it's getting swallowed by the focused progress, but I just ran this:
dagger --progress=plain checks -e 'git://github.com/kpenfound/greetings-api?ref=zenith&subdir=ci'
key being --progress=plain, and can see the problem:
118: exec golangci-lint run
118: > in greetingsapi > lint > Go Lint
118: [0.16s] panic: exec: "golangci-lint": executable file not found in $PATH
118: [0.16s]
118: [0.16s] goroutine 1 [running, locked to thread]:
118: [0.16s] main.shim()
118: [0.16s] /app/cmd/shim/main.go:275 +0xe14
118: [0.16s] main.main()
118: [0.16s] /app/cmd/shim/main.go:64 +0x7c
118: ...
We can look into fixing that separately, but first I'll go see if I can fix the output getting swallowed. I think I probably just need to call focus on some of the vertexes internal to environment machinations
Thanks! Yeah the lint part i was just going off of the go extension which may not be ready. My own lint code was actually failing the lint, i think maybe because of the rewrite. Did the unitTest pass for you?
@pallid girder there are recent changes on the zenith branch that should help. I changed it so all commands except checks will reveal errors by default
Or was this using the zenith branch? 
Im curious, why except checks?
Checks are where failures are expected, and normally bubbled up in a cleaner way vs showing all the internal errors and then duplicating them in the "higher level" output
But there may be ways for that to not work out well too, it's possible there's a better heuristic
Ahh i see what you mean, that makes sense
Maybe something like "if there are errors and none are shown, show all of them"
ah, here's why the unit tests are failing
ci/dagger.gen.go:43:9: fmt.Sprintf does not support error-wrapping directive %w
which refers to the last line here
func init() {
portStr, ok := os.LookupEnv("DAGGER_SESSION_PORT")
if !ok {
panic("DAGGER_SESSION_PORT is not set")
}
port, err := strconv.Atoi(portStr)
if err != nil {
panic(fmt.Sprintf("DAGGER_SESSION_PORT %q is invalid: %w", portStr, err))