Constructicon requires method by which specific version of buildslave resources can be checked

[ncoish]

As it stands, the description of a buildslave in cybertron.py does not provide version information about the resources available on that machine.

For example, if a developer requires a buildslave with a specific version of Rust in order to build their repo, the only information available to constructicon from the slave is that it supports "Rust" with no version information. This could lead to a situation where a developer who requires Rust 0.19.0 is assigned a buildslave which has a lower Rust version, and thus their build will fail.

This becomes doubly confusing if there are multiple machines with differing Rust versions registered to the megatron. In this case, depending on how the machines are assigned, the build may succeed if assigned to the machine with the correct Rust version, and then later fail when a build is triggered on a machine with the incorrect Rust version.

One idea to solve this is to allow for developers to make calls to version checking functions at the time of buildslave assignment, and reject assignment if the version does not match.

[dansgithubuser]

Welcome to constructicon!

constructicon's stance right now is that maintainers and users communally agree on a feature specification. So current implementation would require maintainers to specify a version on each slave, and users to write python expressions to consume. This is understandably frustrating.

One issue that may not be clear here -- as to why the accept is a python expression and not an arbitrary script (afaik) -- is that arbitrary code should not be allowed to run on megatron. Whereas a user accidentally submitting a "rm -rf /" to a buildslave is a local catastrophe, doing the same on the megatron could spell doom for the entire effort (maintainers are encouraged to back their stuff up in any case).

The version checking functions avoids this problem by having a curated list of non-deadly functions to run baked into constructicon itself; maintainers and users still have to agree on which to use, but a lot of the frustration is gone.

In that case, however, another less-obvious issue comes to the fore: the commands must be run on the slave, not the master. So far all commands run on slaves are done through a builder, and I don't envision an easy way to do this differently. Yet we also want to do this check before we create a builder associated with slave X that can't run that builder.

Perhaps there should be another builder added to megatron that can run commands from this library.

I'll assign this issue back to you for further investigation -- it's not something I can currently justify putting on my plate.