[riot-devel] Alternative CI server
Dear RIOTers, we are happy to inform you that our alternative self-hosted CI server (reachable via: https://ci.riot-os.org/riot-os/riot) is now online and ready to process your pull requests on Github. This is why, from now on, you will see two status messages on every new pull requests (one from Travis and one from the alternative system). What does this mean for you as contributor or maintainer? Merge decisions will still be based on the output of Travis. However, you might want to check the output of the alternative system to get faster feedback on your code changes. Why are we rolling out our own test infrastructure? The reason for this is two-fold: 1. We want to support features Travis simply cannot supply such as: * Hardware-based tests: executing test cases on target devices * Device volunteering: allowing trusted developers to connect their device over the internet to our test infrastructure, so that hardware-based tests can be run on their devices. 2. We experienced several major service degradations of Travis (often lasting more than several days) over the course of the last few months. We want a system that is more predictable, directly under our control and also customizable. How we use or whether we use exactly this system (together with Travis or by itself) in the future, is a decision of the developer community. That is why we would like to ask you for your thoughts on the alternative CI system. In addition to posts to this mailing list, you may also create an issue on our issue tracker: https://github.com/RIOT-OS/RIOT/issues?q=is%3Aopen+is%3Aissue+label%3ACI-Infrastructure Here are some additional facts you might find useful: 1. The current state of the server: * The CI server software we are using is Strider-CD ( https://github.com/strider-cd/strider) * The current set of functionality is comparable to Travis (except for some UI issues which are subject to change) * The run time for static tests only (PRs with a missing 'Ready for Ci build' label) is less than a minute * The build queue only serves RIOT. Therefore, the backlog of build/test jobs on the server is relatively small * Test results are currently displayed as one log file with a test summary at the end. This is subject to change in the near future. * Full PR tests take about 45 min. to finish. If tests are skipped by the build script, this number is considerably lower (around 20 min.) * We are considering migrating the system to a more powerful machine. On a modern Core-i7 tests/builds finish after about 25-30 min.. We hope to further decrease this time with some fine-tuning of the build script. 2. Future plans: * UI changes: build matrix instead of just one log file * Hardware tests allowing automated tests to be run directly on devices * Device volunteering * Build slaves for scalability Best, Philipp ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] C++ toolchain issue on ubuntu 14.04
Hi all, I am currently trying to run the cpp tests (e.g. tests/cpp11_*) for stm32f4discovery on ubuntu 14.04 unfortunately all tests I ran failed (see error log at the bottom of this mail). I highly suspect that this is a toolchain issue (btw: happens only with stm32f4discovery). Did I miss something obvious like a missing package (see package list below)? Best, Philipp The relevant packages I have installed are: $ dpkg -l | grep arm-none ii gcc-arm-none-eabi 4.9.3.2015q1-0trusty13 amd64A GNU-based tool chain for arm embedded processors ii libnewlib-arm-none-eabi 2.1.0-3 all C library and math library compiled for bare metal using Cortex A/R/M ii libstdc++-arm-none-eabi-newlib 4.9.2-20ubuntu1+7 all GNU Standard C++ Library v3 for ARM Cortex-A/R/M processors (newlib) $ apt-cache policy gcc-arm-none-eabi gcc-arm-none-eabi: Installiert: 4.9.3.2015q1-0trusty13 Installationskandidat: 4.9.3.2015q1-0trusty13 Versionstabelle: *** 4.9.3.2015q1-0trusty13 0 500 http://ppa.launchpad.net/terry.guo/gcc-arm-embedded/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status 4.8.2-14ubuntu1+6 0 500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages The error log for cpp11_thread: tests/cpp11_thread$ BOARD=stm32f4discovery make clean all Building application cpp11_thread for stm32f4discovery with MCU stm32f4. In file included from /usr/arm-none-eabi/include/c++/4.9.3/random:38:0, from /usr/arm-none-eabi/include/c++/4.9.3/bits/stl_algo.h:66, from /usr/arm-none-eabi/include/c++/4.9.3/algorithm:62, from /home/philipp/RIOT/sys/cpp11-compat/include/riot/chrono.hpp:30, from /home/philipp/RIOT/tests/cpp11_thread/main.cpp:27: /usr/arm-none-eabi/include/c++/4.9.3/cmath:1120:11: error: '::log2l' has not been declared using ::log2l; ^ /usr/arm-none-eabi/include/c++/4.9.3/cmath:1124:11: error: '::logbl' has not been declared using ::logbl; ^ /usr/arm-none-eabi/include/c++/4.9.3/cmath:1146:11: error: '::nexttoward' has not been declared using ::nexttoward; ^ /usr/arm-none-eabi/include/c++/4.9.3/cmath:1147:11: error: '::nexttowardf' has not been declared using ::nexttowardf; ^ /usr/arm-none-eabi/include/c++/4.9.3/cmath:1148:11: error: '::nexttowardl' has not been declared using ::nexttowardl; ^ In file included from /home/philipp/RIOT/sys/include/vtimer.h:28:0, from /home/philipp/RIOT/sys/cpp11-compat/include/riot/chrono.hpp:33, from /home/philipp/RIOT/tests/cpp11_thread/main.cpp:27: /home/philipp/RIOT/sys/include/timex.h: In function 'const char* timex_to_str(timex_t, char*)': /home/philipp/RIOT/sys/include/timex.h:185:39: error: 'snprintf' was not declared in this scope t.seconds, t.microseconds); ^ make[1]: *** [/home/philipp/RIOT/tests/cpp11_thread/bin/stm32f4discovery/cpp11_thread/main.o] Fehler 1 make: *** [all] Fehler 2 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Testing Task Force
Hi, as Martine already remarked: in the worst case all our test jobs are executed more or less sequentially. Given the fact that most test runs for a single commit take about 60 min. to complete we can reach a delay, between pushing a commit and the start of a test run, of about 1.5 days (on a more or less busy day) BTW: We hope to have an implementation which can replace our current travis setup by the end of the month. I am currently in the process of looking into the source code of travis (it's open-source after all) in order to determine which components can be re-used for our purposes. Best, Philipp 2015-04-15 17:32 GMT+02:00 Martine Lenders authmille...@gmail.com: Okay it takes ~1h to finish a build. My bad. 2015-04-15 17:30 GMT+02:00 Martine Lenders authmille...@gmail.com: Hi, there were ~40 new builds opened yesterday [1] and it takes travis ~30 min to finish a build (and since we are in the fair-use queue it works of the jobs more or less sequentially), so thats why the later ones are pending. I think we can speed up things a little if everyone (who has rights to do that) kills jobs that are not current anymore (due to a PR being updated or force-pushed e.g.) as Kushal proposed in [2]. Cheers, Martine [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests [2] https://github.com/RIOT-OS/RIOT/pull/2793#issuecomment-92205543 2015-04-15 16:02 GMT+02:00 Oleg Hahm oliver.h...@inria.fr: Hey folks from the testing task force, does anyone know what exactly is currently wrong with Travis? I have the impression that it didn't run a single test for RIOT today. E.g. https://github.com/RIOT-OS/RIOT/pull/2764 is pending for 24h hours now. Cheers, Oleg -- The bad thing about Haskell jokes is that let understood = map (isJust . understand) $ repeat joke in or understood == False ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
