cmake: don't trust CI to record time and versions and log ourselves#3996
cmake: don't trust CI to record time and versions and log ourselves#3996lgirdwood merged 2 commits intothesofproject:mainfrom
Conversation
80e1f32 to
83d4258
Compare
|
https://sof-ci.01.org/sofpr/PR3996/build8553/devicetest/ has many failures on TGLH_RVP_HDA and many devices unavailable, @fredoh9 is looking into it. Everything else was green but I just force-pushed version 2 (83d4258) and now version 4 (52eca1b) with some enhancements. |
Never discard stderr. Also fix my older, misleading comment and add a warning. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
83d4258 to
a54fc91
Compare
…selves In an ideal world, every CI engine records and shares the most important CI information: - current date and time in a well identified timezone - git version of the pull request - git version of the moving branch the PR is being merged with In the real world we have multiple CI solutions and they unfortunately cannot not all be trusted to perform their most basic job correctly. Fortunately, they all make at least build logs available so these very few lines of code adding very few lines of output cost near zero extra build time and solve the problem once for all. I feel stupid I didn't do this sooner, this would have saved me hours and hours in vain requests and discussions and in trying to puzzle that information together. Sample output: -- Preparing Xtensa toolchain version.cmake starting SOF build at 2021-03-31T18:09:46Z UTC Building git commit with parent(s): 150fd1e4c968 4249bdb1b305 [other parent if merge] (HEAD -> main) cmake: ... -- GIT_TAG / GIT_LOG_HASH : v1.7-rc1-174-g150fd1e4c968-dirty / 150fd1e4c968 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
a54fc91 to
52eca1b
Compare
|
The main (but not only) offender is of course "Quick"Build. Results like https://sof-ci.01.org/sof-pr-viewer/#/build/PR3993/build6245042 have no (or very well hidden) version or date information which is especially time consuming considering the QuickBuild scheduler takes hours to run or is sometimes completely stuck like it was in the last ~24h. Looks like @zrombel just got it running again? See sample waste of time in #3993 (comment) |
|
SOFCI TEST |
General CI outage quickly fixed by @fredoh9 , thanks a lot ! https://sof-ci.01.org/sofpr/PR3996/build8557/devicetest/?model=CML_HEL_RT5682&testcase=check-suspend-resume-5 is the usual suspend/resume TIMEOUT and https://sof-ci.01.org/sofpr/PR3996/build8557/devicetest/?model=CML_RVP_SDW&testcase=check-suspend-resume-with-playback is I think we don't use |
|
See below "you need to rebase" most common CI misconception and confusion between |
In an ideal world, every CI engine records and shares the most important
CI information:
In the real world we have multiple CI solutions and they unfortunately
cannot not all be trusted to perform their most basic job
correctly. Fortunately, they all make at least build logs available so
these very few lines of code adding very few lines of output cost near
zero extra build time and solve the problem once for all. I feel stupid
I didn't do this sooner, this would have saved me hours and hours in
vain requests and discussions and in trying to puzzle that information
together.
Sample outputs
From https://github.com/thesofproject/sof/pull/3996/checks?check_run_id=2239525672, xtensa-build-all.sh
Other examples at https://sof-ci.01.org/sofpr/PR3996/build8556/build/
Signed-off-by: Marc Herbert marc.herbert@intel.com