This tests if the latest manifest on dockerhub matches the pinned
version. The idea is that PRs are not merged until the pinning is
fixed, so that we can ensure that `make BUILD_IN_DOCKER=1` will
always succeed with the pinned version.
We had a number of issues being reported that in the end were caused
by building with a version of riotbuild incompatible with the source,
because CI and source were updated in lock-step but users forgot to
run `docker pull` to update theirs.
In addition, checking out a random old release/commit will likely fail,
as older source may contain bugs that did not trigger with older
toolchains. To reliably succeed at building, a matching version of
riotbuild needs to be used for `BUILD_IN_DOCKER=1`.
This just pins the version of riotbuild manually, so it needs to be
updated by hand in lock step with updating the docker container.
In addition, the latest image is pulled automatically on mismatch.
Ideally, this would pull the tagged image. But that fails for unknown
reason when using the documented command for this with both docker and
podman with:
manifest for riot/riotbuild@sha256:f5951bc41dfface6cac869181d703e62cbdd3b7976b0946130a38f2e658000b3 not found: manifest unknown: manifest unknown
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
The build system sanity check test script currently does not pass
shellcheck, preventing PRs improving it from getting merged.
In addition, the github annotation was broken.
This commit fixes the issues pointed out by shellcheck as well as
the Github annotation.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
This include what you use (IWYU) pragmas so that clang based linters
(such as clangd) treat the use of `xtimer_...()` functions as a use
of the `xtimer.h` header, even if the implementation of those functions
come from a compatibility wrapper.
The dark magic used used in thread_measure_stack_free() is frowned upon
by valgrind. E.g. valgrind may deduce (by monitoring the stack pointer)
that a specific value was at some point allocated on the stack, but has
gone out of scope. When that value is now read again to estimate stack
usage, it does look a lot like someone passed a pointer to a stack
allocated value, and that pointer is referenced after that value has
gone out of scope.
This is "fixed" by temporarily disabling valgrind error reporting while
iterating over the stack.
If there is an Ethernet peripheral (periph_eth feature provided), we
can conclude that an Ethernet network interface can be provided.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
