release runner doesn't include enough context for some errors



6 years ago
4 years ago


(Reporter: aki, Assigned: bhearsum)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



6 years ago
This is a snippet from the release runner email, which is missing the actual mozconfig errors that needed fixing:

2013-05-14 16:20:15,744 : CRITICAL : Tests Failed! Not running sendchange!
2013-05-14 16:20:15,744 : CRITICAL : Failed tests (run with -b to skip) :
2013-05-14 16:20:15,744 : CRITICAL : verify_mozconfig
2013-05-14 16:20:15,762 - INFO - mark as failed Fennec-22.0b1-build1
2013-05-14 16:20:15,923 - INFO - mark as failed Firefox-22.0b1-build1
Traceback (most recent call last):
  File "", line 349, in <module>
    ssh_username=hg_username, ssh_key=hg_ssh_key)
  File "/home/cltbld/release-runner/tools/lib/python/util/", line 469, in apply_and_push
    changer(localrepo, 1)
  File "", line 338, in process_configs
  File "/home/cltbld/release-runner/tools/lib/python/util/", line 40, in run_cmd
    return subprocess.check_call(cmd, **kwargs)
  File "/usr/lib64/python2.6/", line 498, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['python', '../../buildbot-helpers/', '--branch', 'mozilla-beta', '--username', '', '--version', '22.0b1', '--build-number', '1', '--release-config', '', '--skip-verify-configs', '--masters-json-file', '', '--configs-dir', 'buildbot-configs', '--configs-branch', 'production', '--bypass-l10n-dashboard-check', '--dry-run']' returned non-zero exit status 1

The full log is available on buildbot-master36 in /var/log/supervisor/release-runner.log
I'll sleep for 60 seconds before retry
Summary: release runner email loses errors → release runner doesn't include enough context for some errors
Bumping up the number of lines we grab from the log here might help:

No guarantee that you'll get every error though. If one locale fails at the start of release sanity and everything else passes, you might need to look 100 lines up. If you always include 100 lines of context, you may end up with output from a previous run. Maybe we should be logging to a different file on every run or something, so we can include the entire output?
Priority: -- → P3

Comment 2

6 years ago
Including in the email (just the url) might help :)
Product: → Release Engineering
Better idea, from bug 1042056:
(In reply to Ben Hearsum [:bhearsum] from comment #2)
> (In reply to Rail Aliiev [:rail] from comment #1)
> > Maybe use last 1000 lines and attach as text? 100 won't be enough I bet.
> Yeah, maybe. My only concern is that you may end up with context from a
> previous run of release runner. Maybe we can have max 1000, but walk
> backwards only until we see "Fetching release requests" to avoid getting a
> previous run?
Created attachment 8462801 [details] [diff] [review]
crazy bash magic

Pete, in addition to Rail being away, you are our resident bash expert. Someone in #bash gave this to me, and it seems to be working. I'm not sure if there's caveats that I'm not aware of though. It seems to work fine on the current logs in buildbot-master81:/builds/releaserunner - so you can poke around that if you want some sample data. Please make sure not to run itself though.
Assignee: nobody → bhearsum
Attachment #8462801 - Flags: review?(pmoore)
Just the name of the patch has got me all excited!!
Comment on attachment 8462801 [details] [diff] [review]
crazy bash magic

Review of attachment 8462801 [details] [diff] [review]:

Awesome stuff. Nice to see you using sed. May it rule the world. Forever.

::: buildfarm/release/
@@ +58,5 @@
>      sleep $SLEEP_TIME;
>  # Any other non-zero exit code is some other issue, and we should send mail
>  # about it.
>  elif [[ $RETVAL != 0 ]]; then
> +    # Super crazy sed magic below to grab everything from the last run.

Technically, this is not bash magic (e.g. you could run the same sed from csh) - it is wonderful, beautiful, and dignified sed magic!! :D

@@ +63,3 @@
>      (
>          echo "Release runner encountered a runtime error: "
> +        sed -n 'H;/Fetching release requests/x; ${;g;p;}' $LOGFILE

This works fine, but the I think h command would be better (clearer) than x, and some comments might help. 'x' is exchanging the hold and pattern space, but pattern space does not need to be updated (it is replaced as soon as next line is read anyway). 'h' instead just updates hold space with contents of pattern space, which is all that we need to do.

sed -n '
    # append each line to the hold space as we iterate through the file
    # if we find "Fetching release requests" text somewhere in a line,
    # ditch hold space buffer and replace with just the new line read
    /Fetching release requests/ h
    # when we reach end of file ($) we need to output hold space
    $ {
        # copy hold space into pattern space
        # print pattern space
Attachment #8462801 - Flags: review?(pmoore) → review+
As you see above, you can put comments directly in the sed code, which I think would make it more readable. Also see you can run the sed command over several lines, because bash allows you to open a string with a ' on one line, and close it several lines later with the closing '. With the formatting, and the commenting together, it might be clearer to a bash novice, what is going on.

Another point I forgot to mention - you could add a comment to explain the sed "-n" option, i.e. to prevent each pattern space being printed with each iteration, so the only output is when you reach the end of the file, and explicitly output the hold space (by first copying it to the pattern space, and then printing that - no command to directly print hold space in sed).
Lastly, if the log file could be *massive*, it may be cheaper to run
tail -r "${LOGFILE}" | sed -n '1,/Fetching release requests/p' | tail -r

If it isn't massive (i.e. hundreds of megabytes or more) you don't need to read ahead. :)

In this alternative implementation, tail -r is outputting the lines of the log file in reverse order, the sed is matching all lines up-to-and-including the first line containing "Fetching release requests", and the second tail -r is then reversing the output again, back into the correct order - so in the end you get the same thing - everything from the *last* line containing "Fetching release requests" to the end of the file.

Personally, I think the sed solution is prettier, but this may be more efficient (assuming tail -r is reading/outputting on the fly and does not read the entire file into memory before outputting content). Another advantage of this approach, is that when sed finishes, it will cut tail -r off - so if there are millions of lines in the file but only 10 to be read, shortly after tail -r has read the last 10 lines of the log file in reverse order, it will stop reading earlier ones. In the sed implementation it will read the entire log file, dumping each "run" into memory (into its hold space) even if it only outputs 1% of the log file in the end.
Created attachment 8463381 [details] [diff] [review]
documented crazy sed magic

I actually find it easier to read this as a sed one liner...I also don't think I can embed docs because this is within a (), so I've put the docs above that. I even realized an edge case in writing them, wheee!
Attachment #8462801 - Attachment is obsolete: true
Attachment #8463381 - Flags: review?(pmoore)
Comment on attachment 8463381 [details] [diff] [review]
documented crazy sed magic

Review of attachment 8463381 [details] [diff] [review]:

Awesome. :)
Attachment #8463381 - Flags: review?(pmoore) → review+
Comment on attachment 8463381 [details] [diff] [review]
documented crazy sed magic

Landed, and updated the checkout on bm81 to make it live.
Attachment #8463381 - Flags: checked-in+
We won't be able to fully confirm this until we hit another error, but it's landed.
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.