Closed mattmoor closed 1 year ago
Here's the action leg: https://github.com/chainguard-dev/terraform-provider-apko/actions/runs/4916989168/jobs/8781471552?pr=52
I pasted the trace above because github doesn't retain logs indefinitely and wanted to avoid losing this since it's rare.
Do you know what the flow is to trigger this? I don't mean exercising the entire tf-apko, but the specific calls that make it happen?
I don't quite know enough about how tf-apko works, what it calls, etc.
@deitch it is really just invoking apko
as a library based on config read from TF instead of passed in via CLI args.
I have only seen this once, so I don't think there is any particular magic to reproduce it, but I am curious if we run any of our tests for this stuff with -race
, which might reproduce more reliably?
Clearly not in this workflow. But I was sure someone had added it. Maybe it didn't make it in? Huh.
Care to open a PR adding -race
there, and we can let it run, catch it, fix issues?
Looks like the same callstack at the top of what -race
found in the linked PR:
github.com/chainguard-dev/go-apk/pkg/fs.(*memFS).OpenFile()
/home/runner/work/go-apk/go-apk/pkg/fs/memfs.go:215 +0x19b
github.com/chainguard-dev/go-apk/pkg/fs.(*memFS).WriteFile()
/home/runner/work/go-apk/go-apk/pkg/fs/memfs.go:259 +0x96
Saw this in
tf-apko
's presubmit testing. It was just once, but also without-race
so perhaps that'll flush it out quicker because I've never seen this before.cc @deitch
Full panic trace below: