After my latest rebase on master I’ll get an " Some checks were not successful" info and some checks are red cross marked.
When I look in the corresponding logfile, I find a reference to a file e.g.: (see /tmp/buildlogs/HeliCopter-LoggerDocumentation.txt)
But where I can find that file? And will that file contain further info?
That reference is done some more in the logfile, but I can’t see the root cause for that error:
hello,
you can find the log into the Artifacts package on the test page : on right up in your pictures !
Otherwise, you could just scroll up on the check output until you reach the failure on the named test.
In addition to @khancyr 's notes, I’ve found downloading the raw log and searching for the text in question works quite well.
Thank you both, that brought me a little step forward.
Now I located where the failure happened, but I need help to interpret the traceback and find the connection to my code:
CI error.txt (4.1 KB)
Ok, not to get an answer is an answer, too. 
It means: Shut up, open your eyes and use your brain.
I found the line where the error occurs, but I don’t understand what that parser is checking - so a little hint would be very welcome.
Is there any documentation that describes that investigation process after a CI error? Or is it just developer business that “everybody” knows?
I’m afraid it really usually means digging into the block of text and working out what went wrong.
This is what draws my eye:
2021-01-06T16:11:25.9702692Z Running: ("/__w/ardupilot/ardupilot/Tools/autotest/logger_metadata/parse.py" "--vehicle" "Copter") in (/tmp/buildlogs)
2021-01-06T16:11:25.9704088Z AT-0184.9: Exception caught: Command '['/__w/ardupilot/ardupilot/Tools/autotest/logger_metadata/parse.py', '--vehicle', 'Copter']' returned non-zero exit status 1.
2021-01-06T16:11:25.9705079Z Traceback (most recent call last):
2021-01-06T16:11:25.9706225Z File "/__w/ardupilot/ardupilot/Tools/autotest/common.py", line 4837, in run_one_test
2021-01-06T16:11:25.9706807Z test_function()
2021-01-06T16:11:25.9707445Z File "/__w/ardupilot/ardupilot/Tools/autotest/common.py", line 1920, in test_onboard_logging_generation
2021-01-06T16:11:25.9708243Z if util.run_cmd(cmd, directory=self.buildlogs_dirpath()) != 0:
2021-01-06T16:11:25.9708953Z File "/__w/ardupilot/ardupilot/Tools/autotest/pysim/util.py", line 77, in run_cmd
2021-01-06T16:11:25.9709704Z return subprocess.check_call(cmd, shell=shell, cwd=directory)
2021-01-06T16:11:25.9710398Z File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
2021-01-06T16:11:25.9711057Z raise CalledProcessError(retcode, cmd)
2021-01-06T16:11:25.9712498Z subprocess.CalledProcessError: Command '['/__w/ardupilot/ardupilot/Tools/autotest/logger_metadata/parse.py', '--vehicle', 'Copter']' returned non-zero exit status 1.
2021-01-06T16:11:25.9713513Z
Best bet to find that is to run the same command locally and see what it says.
That are the results of the local checks:
But a try to start the whole test results in a general error:
So I no longer trust in my cygwin dev-environment. I’m still working with python2.7 and I hoped that it will last 'till my PR is merged, but it seems to be necessary to update immediatelly.
Ok, update done and root cause for parser-error detected and eliminated.
That has been the way:
As @peterbarker recommended I started the test locally and it told me that the parser can’t decode a byte 0xb0
In utf-8-table I looked for that value and found the degree-sign °
So I looked for that character in my changed/new files and found it:
(a more easy way could have been to search with grep or Wingrep for 0xb0)
So after the correction that parser-error is gone. 
So it’s only one failed check left, but to understand the nature of that seems not to be so easy:
I run the check locally before I rebased (to initiate the checks on GitHub again)
and it passed with no error:
And I run the check locally after I rebased
and it passed with no error:
That seems to be the interresting block in the logfile:
So I need help and support to understand that failure, because
Detected motor peak at 135.416116Hz, throttle 37.000000%, 5.993526dB
doesn’t tell me anything.
Ok, I digged a little deeper and found the check fly_gyro_fft_harmonic in arducopter.py:
arducopter_fly_gyro_fft_harmonic.py.txt (7.0 KB)
So I wonder how my code in an AUTO-library (AP_Mission) will influence that test in mode ALT_HOLD?
Who is the owner of arducopter.py and could help and clarify that?
Hi @Quaxwilly
There are a few tests that often fail randomly and its mostly not the PR’s fault. From experience, FFT Harmonic test happens to be one of them. Just run it once again and it should fix itself.
Thank you Rishabh - that still drove me crazy, 'cause I coudn’t find the connection to my code.
Some things are very easy - if you just know it
