#our ebpf build & generate pipeline

1 messages · Page 1 of 1 (latest)

warped nebula
#

🧵

#

Specifically:

  • dagger call engine-dev generate calls go generate but then removes some of the ebpf-related .o files
#
  • those .o files are go:embed-ed but they're checked in as empty files?
#
  • Engine engine-dev/builder re-runs go generate of those files at build time I think?
spare timber
#

Yeah that's how it works, you use go:embed and thus the file must exist for a build to succeed, but you don't want to check them in because they are binary blobs. So you only generate them during a build, never check them in

#

So we want to skip them in terms of checking "ohh there was a diff after running go generate!"

warped nebula
#

If they're .o do they really belong in go generate?

#

I guess the alternative is that they require a custom wrapper and native go toolchain can't get to a clean build without it

spare timber
#

That's fine though if it's a big thorn to have them run with go generate

warped nebula
#

So this seems like a more general problem with Go + ebpf ecosystem?

spare timber
#

Another solution would be to just check the blobs in... they aren't actually very big. It just feels gross to check in non-source code. But tbh I doubt it's much of a big deal in practice

#

They might be smaller than the generated core bindings for a module 😄

warped nebula
#

let me research real quick how the go ecosystem deals with this problem

#

This is a multi-variable equation for me btw: I'm generally aiming in the direction of reducing the number of project-specific dagger modules... But I'm also researching how many project-specific dagger modules is reasonable and good

#

So there's always the risk of taking the "generalize all the modules" idea too far. I know there's a line (I don't see us completely removing engine-dev...) but I don't know where that line is exactly

#

Even a project-specific builder like engine-dev has an interesting twist to it: imagine if it became a standalone module, capable of cleanly building any version of the engine

#

That's not actually the same thing as an embedded script that can run exactly one version: the one it's embedded with

#

This 👆 crossed my mind when we discovered that we actually can't reliably re-build all past versions anymore

#

Even v0.20.3 is no longer buildable

spare timber
#

One possible way of keeping it generic would be to just have support for ignoring some selected generated diffs. If we could just say "do not consider those .o when checking if there's any diffs after go generate", that would also solve the problem. But would also not be extremely specific to this scenario

warped nebula
#

(because of a breaking change in zig URLs, which more recnet versions of the builder is robust to, but the version bundled with 0.20.3 and earlier is not)

warped nebula
#

Feels like if done right, that could be the elegant solution

spare timber
warped nebula
#

@spare timber well look at this:

We recommend building eBPF C code from within a container with a stable LLVM toolchain, as well as checking all generated .o and .go files into source control. This buys you fully-reproducible builds, prevents bugs due to team members using different LLVM versions and makes your packages fully independent and go runnable. It also prevents PII from leaking into ELFs in the form of absolute paths to .c source files in DWARF info.

https://ebpf-go.dev/guides/portable-ebpf/

spare timber
#

Oh yeah, so they just say to check in the .o. They are not normal .o bin files, they are ebpf bytecode, so they are quite small. But we will have some binary blobs in our repo technically

#

I'm honestly fine with that as long as others are

warped nebula
#

it does weigh a lot that the official toolchain docs recommend it

warped nebula