x/build: add LUCI linux-mipsle builder

[dmitshur]

There currently isn't a LUCI builder that tests the linux/mipsle port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

CC @golang/mips.

[stffabi]

We were lately in contact with @FiloSottile and he pointed us to this issue and the risk of the MIPS Go port might get dropped due to missing LUCI builders. Our company heavily relies on the MIPS Go port and we would like to provide the infrastructure for several of such builders.

This is the first time we are looking into providing a LUCI builder so I have a couple of questions.

• MIPS is now almost exlucisively used in embedded devices and routers. Therefore it's hard to get any decent powerful hardware for CI stuff. Should those runners be bare metal, or are e.g. QEMU emulated runners fine?
• We could provide several MT7688A based nodes (this is our current hardware in use), but specs are limited.
  • MIPS24KEc single core 580MHz
  • 128MB Memory
• We would have the possibilty to get our hands on several MT7621 nodes with the following specs:
  • MIPS1004Kc dual core 880MHz
  • 256MB Memory

To get a feeling of how our current hardware would perform, is there some documentation what would be run on those runners?

• Will they build the whole Go tree?
• Are the test suites cross compiled to MIPS on other runners and only the test suites run?
• Are there some docs, where wou could manually run the tasks to get a feeling of how long the build times would be?

[dmitshur]

Thank you for offering to provide the builders, and apologies for the delay in getting back to these questions.

Therefore it's hard to get any decent powerful hardware for CI stuff. Should those runners be bare metal, or are e.g. QEMU emulated runners fine?

The ideal hardware for a builder to use is something that most closely resembles the target port being tested, such that it's findings are most likely to be true positives with minimal false negatives. QEMU emulation adds an additional layer of indirection, and may introduce some false positives. But if there isn't too much noise, it's entirely possible that the benefit from the speed up you're able to get that way outweighs the downsides of adding that layer. Ultimately, it's up to the you as the builder owner to decide what builder setup to aim for, based on how well it'll serve and how well you can keep it running.

Note that the builder requirements written down at https://go.dev/wiki/DashboardBuilders#builder-requirements list 512 MB as the minimum, so with only 128 or 256 MB of memory, you'd be below the supported range and may run into trouble.

• Will they build the whole Go tree?
• Are the test suites cross compiled to MIPS on other runners and only the test suites run?
• Are there some docs, where wou could manually run the tasks to get a feeling of how long the build times would be?

As I answer these questions below, please keep in mind that what I'm describing is the default builder setup for ports that have high performance hardware available. It is possible to reduce the scope of testing for certain ports/builders if there's not sufficient builder resources available, but that reduces coverage of testing. See some related discussion in #67105 (comment).

By default, builders build and test the main Go repository and all golang.org/x repositories on the main branch ("master") and all supported release branches (e.g., "release-branch.go1.22" and "release-branch.go1.23").

In the default case, builders testing a given port are responsible both for building and testing. This increases coverage (proof that the target OS/arch can be used to build successfully) and makes it easier to have cgo enabled. In special cases, like the Plan 9 builders that can't run the LUCI swarming client due to absence of the python3 dependency, it's possible to arrange for a Linux host to do the building and perform test execution remotely. See #62025 (comment) for details.

For the main Go repository, the builders run the equivalent of all.bash. For golang.org/x repositories, they run the equivalent of go test -short ./... for all modules. You can run those commands locally to get a good idea of the performance to expect.

I hope that helps. When you're ready to proceed, see step 2 of https://go.dev/wiki/DashboardBuilders#how-to-set-up-a-builder (step 1 is already done; it's this issue).