-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.murdock: disable hash checks of kconfig/make #18423
.murdock: disable hash checks of kconfig/make #18423
Conversation
Much CI time is waisted as unrelated hash failure occur. Finding out why is taking some time. In order to stop killing dolphins we will disable only the hash checks. There is a risk of introducing new issues with the kconfig/make dependency resolution. However, the package/module checks are still enforced which should catch 95% of the problems. The nightlies will continue to check as well.
Looks like you caught a difference in the module list that was not impacting the binary hash |
I imagine there are a few of these. |
It seems the failures are caused by Introduced in #16787, ping @maribu if you want to confirm my off-the-cuff logic. |
I think this may be more complicated, as the |
This creates diff failures when calling info-modules and info-packages. Ideally info-modules and info-packages have clean output for the CI build
This probably can be done better as the periph_eth should not be only part of the stm32 as the sam0 also uses it.
As this is not handled in the makefile.dep it does not need to be modeled in kconfig.
ea9a356
to
a00060f
Compare
As this prevents the hash failures we should not skip this and rather enable automerge so we will have it in some time tonight. |
Thank you for the review |
After introducing RIOT-OS#18423 there are occasional messages that still happen. These messages cause a diff output when testing with TEST_KCONFIG=1. This then causes a failure when comparing make/kconfig modules and packages.
After introducing RIOT-OS#18423 there are occasional messages that still happen. These messages cause a diff output when testing with TEST_KCONFIG=1. This then causes a failure when comparing make/kconfig modules and packages.
After introducing RIOT-OS#18423 there are occasional messages that still happen. These messages cause a diff output when testing with TEST_KCONFIG=1. This then causes a failure when comparing make/kconfig modules and packages.
After introducing RIOT-OS#18423 there are occasional messages that still happen. These messages cause a diff output when testing with TEST_KCONFIG=1. This then causes a failure when comparing make/kconfig modules and packages.
After introducing RIOT-OS#18423 there are occasional messages that still happen. These messages cause a diff output when testing with TEST_KCONFIG=1. This then causes a failure when comparing make/kconfig modules and packages.
This was partially cleans up in RIOT-OS#18423 but it looks like this one was missed. Signed-off-by: Dylan Laduranty <[email protected]>
Much CI time is wasted as unrelated hash failure occur.
Finding out why is taking some time.
In order to stop killing dolphins we will disable only the hash checks.
There is a risk of introducing new issues with the kconfig/make
dependency resolution.
However, the package/module checks are still enforced which should catch
95% of the problems.
The nightlies will continue to check as well.
Contribution description
Testing procedure
Check the murdock output? It is pretty hard to test CI changes.
Issues/PRs references
A little less destructive than #18399