Hi Abdelkader, > As part of modernizing util/autoport to current Go idioms (patch on Gerrit), > I bumped the minimum Go version to 1.26. > > This got me thinking about a broader usability improvement: right now anyone > wanting to use autoport to port a new board needs Go installed locally or do > it in another machine. This is the friction i want to remove. > > My proposal is add a GitHub Actions workflow that triggers when util/autoport > is modified, builds a static Linux x86_64 binary, and publishes it as a > GitHub release. Contributors can then just download and run it without > setting up a Go toolchain. People who want to compile everything, still can.
One note about autoport is that it relies on other utilities in util, namely ectool, inteltool, and superiotool. So if we want to ship binaries for autoport, I think it would make sense to also ship binaries for the other utilities it requires. That said, those are written in C, and it's less likely someone doesn't have a C compiler compared to Go. > Questions before going further: > - Is there appetite for this in the project? I think there could be. We already ship precompiled versions of the toolchain as a docker container (see coreboot-sdk), though that is only updated periodically. I'm not sure autoport would work properly in docker anyway given that some of the utilities it requires need root permissions and low level hardware access. There are some distro packages for coreboot's utils, though I don't think those are necessarily maintained by coreboot officially. > - Can coreboot's GitHub mirror have Actions enabled, or would this need to > live elsewhere? (i know it only a mirror, but that could be enable > exclusively there for all the tooling (I could also see how to do it with > jenkins). If we're going to bother with building these in CI, then it probably would make sense to use our current CI infrastructure and also have it publish build results to Gerrit. There currently is a gap in build testing for things like some less common payloads and a lot of the utils. Setting up CI tests also opens up the door to having autoport ran against some test inputs to verify that it still functions after a change to its own code, as well as that it still generates valid code when changes are made to coreboot's code. There have been a few times that autoport fell behind changes made to coreboot's code for an extended period of time. Cheers, Nicholas _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
