Also upload the artifact to GitHub action, and in addition use the same setup
(ubuntu 20.04 image) and build directories as done on builds.robur.coop.
Also use `strip` on the resulting binary to reduce it's size (since the debug
section aren't mapped into the running unikernel, there's nothing we get from
them -- also they are preserved (as .debug file) and uploaded to
https://builds.robur.coop if one needs them).
This entails binary reproducibility between the different systems:
- a developer using ./build-with-docker.sh
- GitHub action (run on every PR)
- builds.robur.coop with the ubuntu-20.04 worker
in the callback to "Xs_client.wait", all operations are tracked and new watches
are installed (that are never removed, due to xenstore's xs_handle
"accessed_path" never removes any elements of the "accessed_paths" (a mutable
StringSet). So, whatever is done in the callback of wait needs to take care
(if returning EAGAIN and thus forcing xenstore to continue waiting/watching)
that accesses are tracked.
Our way out is to create a fresh client and read the IP address with that new
client -> the watcher isn't extended -> no dangling (leaking) watches, and no
leaking only-expanding StringSet.
Before, a DNS request was sent and the first thing appearing in the Lwt_mvar
was taken as reply. The issue with this was two-fold:
- it could be a reply for a different request
- there could be DNS replies being sent to the uplink stack leading to
Lwt_mvar.put being called, which blocks if there is already a value in the
mvar.
No, the separate task is a loop reading the mvar, using a Lwt_condition to
signal the receive of that ID (potentially discarding if there's no client
waiting). The DNS query registers itself (using the ID) in the map with a
Lwt_condition, and waits to be notified (or a timeout occurs).
