430942 - If bug # given and try syntax specifies it, automatically add a comment with build results to the bug when builds/tests are finished

Status: RESOLVED FIXED

(Release Engineering :: General, enhancement, P2)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

If the custom id/description field contains a bug number, it would be nice if the try server could automatically add a comment in bugzilla saying something like "New tryserver builds referencing this bug are available at http:///...../".  (Perhaps a new explicit bug # field could be added alongside description/etc.)

Comment 1

[[e-mail] (:bhearsum)]

Want.

Unless someone else wants to do this sooner I'll do it with the next round of try server upgrades (probably Q3).

Comment 2

[[e-mail] (:bhearsum)]

Mass change of target milestone.

Comment 3

[Aki Sasaki (not active)]

Futuring.

Comment 4

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(Closed during triage a few weeks ago, but no comment, so not sure why. Reopening while we figure out what we were thinking!)

from irc, 
- not sure if this is still needed, because we now have email notifications for tryserver jobs?
- we keep tryserver jobs for 14 days, so those buglinks will quickly break. Maybe thats ok for users of tryserver, but just to be clear.

Comment 6

[[e-mail] (:bhearsum)]

I think that the more important aspect of this bug is adding the status of the try server run, rather than a download link. I can see a lot of value in having a permanent record of "did this patch pass on try?"

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yep, even if the link said "valid until m/d/y" it would still be helpful, because the tryserver run would be useful for people who are actively tracking that bug.  This would require a bit more work though, such as waiting until all the try server builds for the patch were done before notifying/adding, or until a category of them was done (which would be great for email too, incidentally; "Build finished, success on Mac and Linux, failure on Windows" etc. instead of the dozen+ emails now).

Anyway, could use a bit of design work to figure out what ideal tryserver/bug/etc. flow could look like.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Adding this to the bugs tracked by the try_enhancements bug. When we get to
doing a road map for the next iteration of try improvements it will be visible
there for review and prioritization.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: try bugposter v.1

I've added this to braindump in a try-related dir.  Tested locally (connected to build-vpn) and have it working. Currently set POST_TO_BUGZILLA to false so as not to overpost to https://landfill.bugzilla.org/bzapi_sandbox/show_bug.cgi?id=9949 but as you can see, the bug posting works.  I'll need to substitute the API info and add a local config with cltbld's bugzilla credentials.  Also will need to broadcast to developers the ability to add a bug # and a '--post-to-bugzilla' flag to their push comment.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: try bugposter v.1 (with consistent 4 space indenting)

Comment 12

[Chris AtLee [:catlee]]

Comment on attachment 501450 [details] [diff] [review]
try bugposter v.1 (with consistent 4 space indenting)

Bit of a lengthy review here.

>diff --git a/try-related/bz_utils.py b/try-related/bz_utils.py
>new file mode 100644
>--- /dev/null
>+++ b/try-related/bz_utils.py

It may be worth considering putting bz_utils.py into tools, or somewhere where
other scripts can make use of it.

>diff --git a/try-related/e2e.html b/try-related/e2e.html
>new file mode 100644
>--- /dev/null
>+++ b/try-related/e2e.html

These two test files should go into a 'tests' directory or something.

>+import re, os, ast, urllib
>+try:
>+    import simplejson as json
>+except ImportError:
>+    import json
>+import bz_utils as BugzillaAPI

Why rename the module here?
>+
>+FLAG = ""
>+FILENAME = 'try_incomplete.cache'
>+POST_TO_BUGZILLA = False
>+E2E_URL = "http://cruncher.build.mozilla.org/buildapi/reports/endtoend/try?format=json"
>+REVISION_URL = "http://cruncher.build.mozilla.org/buildapi/reports/revision/try/%s?format=json"
>+
>+### BUGZILLA API GLOBALS ###
>+API = "https://api-dev.bugzilla.mozilla.org/test/latest/"
>+### TODO: Read this from local config
>+USERNAME = "[e-mail]"
>+PASSWORD = "password"

Pretty much all of these should be set in a configuration file, which TryBugPoster reads.

>+class TryBugPoster():

No need for an empty inheritance specification.

>+
>+  def GetBugNumber(self, comment, flag="", flag_check=True):
>+      # Searches the pushes comment string for a bug number and optionally a flag and returns only the bug number if criteria is met

These initial comments (and in functions below) should be docstrings.  Also,
can you expand on what 'flag' is, and what it's used for?

There's a more robust bug-number-parsing function in
http://hg.mozilla.org/graphs/file/91bdf3d3cf29/server/analysis/analyze_talos.py#l128

>+      try_match = re.search('try: ', comment)
>+      if flag_check:
>+          flag_match = re.search(flag, comment)
>+          if try_match and flag_match:
>+              # Search for '{B,b}ug $num' where $num is between 4-6 numbers
>+              bug_num = re.match(r"[Bb]ug *[0-9]{4,6}", comment)
>+              if bug_num:
>+                return bug_num.group(0).split()[1]
>+      else:
>+          if try_match:
>+              # Search for '{B,b}ug $num' where $num is between 4-6 numbers
>+              bug_num = re.match(r"[Bb]ug *[0-9]{4,6}", comment)
>+              if bug_num:
>+                  return bug_num.group(0).split()[1]
>+
>+  def LoadCache(self, filename):
>+    # check for an existing cache file, and returns a tuple of contents and errors
>+    loadedCache = {}
>+    errors = ""
>+    if os.path.isfile(filename):
>+        print "Located existing cache file, reading contents"
>+        with open(filename, 'r') as f:
>+            for line in f.readlines():
>+                try:
>+                    (build,info) = line.split(':',1)
>+                    loadedCache[build] = "%s" % ast.literal_eval(info.strip())
>+                except:
>+                    errors += "%s is not in correct format and cannot be read into the list" % line
>+    else:
>+        print "No existing cache file, one will be created to track incomplete builds"
>+    return (loadedCache,errors)

Inconsistent indentation here in this function.  Also, please use the logging
module instead of print statements.  You also need spaces after ',' in a few of
your tuples.

>+
>+  def UpdateCache(self, loadedCache, builds):
>+    # accepts a dictionary from cache, and the dictionary of current incomplete builds
>+    # returns a tuple of builds to be tracked in cache and the ones ready to post on bugzilla
>+    outgoing = {}
>+    bugmail = {}
>+    for c in loadedCache.keys():
>+        if c in builds.keys():
>+            outgoing[c] = loadedCache[c]
>+            print "Keeping %s in cache, still not complete" % c
>+        else:
>+            bugmail[c] = loadedCache[c]
>+            print "Added %s to bugmail list" % c
>+    for b in builds.keys():
>+        if b not in outgoing.keys():
>+            outgoing[b] = builds[b]
>+            print "Added new buildrun %s to outgoing cache list" % b
>+    return outgoing,bugmail

Inconsistent indentation, missing spaces, and print statements here too.

>+
>+  def WriteCache(self, filename, builds):
>+      results = None
>+      # write to file each revision:bug_number that has running/pending builds
>+      try:
>+          with open(filename, 'w') as f:
>+              for b in builds.keys():
>+                  f.write("%s:%s\n" % (b, builds[b]))
>+      except:
>+          results = "Unexpected error:", sys.exc_info()[0]
>+      return results
>+
>+  def GetBuildReport(self, url, revision=None):
>+    # Accepts a revision if the request is for a completed build's information
>+    # return list of query results
>+    # E2E_URL is a complete list of build runs between time of request 
>+    # and 24hrs prior
>+    # R_URL + revision is the detailed info for any revision's build run
>+
>+    if revision:
>+        try:
>+            response = urllib.urlopen(url % revision)
>+        except:
>+            # the url doesn't have an argument in it for revision (test)
>+            response = urllib.urlopen(url)
>+    else:
>+        response = urllib.urlopen(url)
>+
>+    content = response.read()
>+    report = json.loads(content)
>+    if report:
>+        return report
>+    else:
>+        return "No report available"

Inconsistent indentation here too.

>+
>+  def IncompleteBuildRevisions(self, e2e_url, revision_url):
>+    # looks through the end to end report json to collect revisions that are incomplete
>+    builds = {}
>+    bug_number = ""
>+    e2e_report = self.GetBuildReport(e2e_url)
>+    if e2e_report.has_key('build_runs'):
>+        for buildrun in e2e_report['build_runs']:
>+            if e2e_report['build_runs'][buildrun]["is_complete"] == "no":
>+                revision_report = self.GetBuildReport(revision_url, buildrun)
>+                for r in revision_report["build_requests"]:
>+                    if bug_number is "":
>+                        bug_number = self.GetBugNumber(r["comments"])
>+                    else:
>+                        continue
>+                builds[buildrun.encode("utf8", "replace")] = bug_number
>+    return builds

Indentation.  Also, this looks like the first bug number detected will be
applied to all incomplete revisions?

>+
>+  def BuildRunInfo(self, revision_report):
>+    # Accepts the json information for a revision
>+    # return a tuple containing the formatted info on the build run and the bug number from the pushlog comments if one is present: 
>+    # "Try run for {revision} had {total_builds} build requests and {total_complete} completed. The results are:
>+    #  success: {success_num}
>+    #  warnings: {warning_num} 
>+    #      * {list_of_warning_builders}
>+    #  failed: {failure_num}
>+    #      * {list_of_failure_builders}
>+    #  unknown: {unknown}
>+    #      * {list_unknown)
>+    #  More information is available here: {link_to_logs? tbpl?}
>+
>+    buildRun = ""
>+
>+    if revision_report:
>+        revision = ""
>+        complete = ""
>+        bug_number = ""
>+        if revision_report.has_key('complete'):
>+          complete = revision_report["complete"]
>+        total_builds = revision_report["total_build_requests"]
>+        success_num = 0
>+        warn_num = 0
>+        fail_num = 0
>+        unknown = 0
>+        list_warn = []
>+        list_fail = []
>+
>+        if revision_report.has_key('build_requests'):
>+            build_requests = revision_report["build_requests"]
>+            for build in build_requests:
>+                result = build["results"]
>+                bug_number = self.GetBugNumber(build["comments"], FLAG)
>+                revision = build["revision"]
>+                buildername = build["buildername"].encode("utf8", "replace")
>+                if result == 0:
>+                    success_num += 1
>+                elif result == 1:
>+                    warn_num += 1
>+                    list_warn.append(buildername)
>+                elif result == 2:
>+                    fail_num += 1
>+                    list_fail.append(buildername)
>+                else:
>+                    unknown += 1
>+                    list_unknown.append(buildername)
>+
>+        buildRun = """\
>+Try run for %(revision)s had %(total_builds)s build requests and %(complete)s completed. The results are:
>+      success: %(success_num)s
>+      warnings: %(warn_num)s
>+          * %(list_warn)s
>+      failed: %(fail_num)s
>+          * %(list_fail)s
>+""" % locals()
>+
>+        if unknown > 0:
>+              buildRun += """\
>+Also there were %(unknown)s failures on %(list_unknown)s""" % locals()
>+
>+    return (buildRun.encode("utf8", "replace"), bug_number)

Indentation problems here too.

>+
>+  def PostBugComment(self, bug_num, message):
>+    if POST_TO_BUGZILLA:
>+        if bug_num:
>+            BugzillaAPI.bz_notify_bug(API, bug_num, message, "", USERNAME, PASSWORD)
>+    else:
>+        print "Not posting '%s' to bug %s" % (message, bug_num)

Indentation problems here too.

>+
>+def RunTryBugPoster():
>+    """Run at regular intervals to track incomplete build runs and to email/post to bug number in pushlog comments when a build run is completed with the results"""
>+
>+    c = TryBugPoster()
>+    # gather incomplete build revisions in that report
>+    print "Gathering incomplete builds list from %s" % E2E_URL
>+    incomplete =  c.IncompleteBuildRevisions(E2E_URL, REVISION_URL)
>+    print "Checking for an existing cache file"
>+    #check for a cache file
>+    loadedCache = c.LoadCache(FILENAME)
>+    # proceed if no errors
>+    if loadedCache[0] and not loadedCache[1]:
>+        # compare what's in cache to the new list to make two lists: what's done and what's incomplete
>+        print "Comparing cache to current list of incomplete builds"
>+        (newIncomplete,outgoing) = c.UpdateCache(loadedCache[0], incomplete)
>+    elif loadedCache[1]:
>+        print "Errors in loading cache: %s" % loadedCache[1]
>+        return 0
>+    else:
>+        print "Nothing in cache, continuing with only the new list of incomplete builds"
>+        newIncomplete = incomplete
>+        outgoing = None
>+
>+    # write to cache with the incomplete
>+    print "Writing results to %s" % FILENAME
>+    results = c.WriteCache(FILENAME, newIncomplete)
>+    if results:
>+        print results
>+
>+    # send bugmail for each revision with a bug number (and flag) in the outgoing list
>+    if outgoing:
>+        print "Posting bug comments for complete builds"
>+        ## need to do a per bug loop here if the outgoing revision has a bug number
>+        for revision in outgoing.keys():
>+            revision_report = c.GetBuildReport(REVISION_URL, revision)
>+            (comment, bug_number) = c.BuildRunInfo(revision_report)
>+            if bug_number:
>+                bugmail = c.PostBugComment(bug_number, comment)
>+                print "Posted to bug number %s for %s" % (bug_number, revision)
>+            else:
>+                print "No bug number provided for %s" % revision
>+    else:
>+        print "No outgoing list to post to for this run"
>+
>+    return 1

Use logging instead of print statements in this function, and here's where you
would do the configuration file handling instead of using global variables.

>+
>+if __name__ == '__main__':
>+    results = RunTryBugPoster()
>+    if results:
>+        print "Run is complete without error"
>+    else:
>+        print "Run finished with errors"

If there are errors, the process should exit with non-zero status.

>+
>+####  FUTURE TODO  ####
>+# check comments on a bug to make sure we are not putting up a duplicate comment?
>+# allow for an email option instead/as well and search try syntax for an --email flag

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: try_bugposter v2

What's new:
* Everything is now in tools/scripts/tryserver
* Tests and files needed for testing are in a tests directory
* No longer renaming the bz_utils module
* Uses a configuration file instead of globals
* Comments are docstrings, clearer explanation of each function
* Uses more robust bug parser (added to bz_utils)
* Consistent indentation
* Using logging module instead of print statements
* Added spaces after ',' in a few of the tuples
* Added comment to explain how the first bug number detected (in a set of builds for a build_request) will be applied only to the revisions -- this is a response to the previous patch's feedback
* If there are errors, the process exits with non-zero status.

Comment 14

[Aki Sasaki (not active)]

My 2c, which may or may not be overkill:

* Generate a simple html page with links to files/logs with build status of each.  Optionally color coded.  Bonus points for *why* there was an error/warning.
* Upload this html page to the same directory as the files/logs
* The bug comment would say something like "Try run ____: X successful Y warning Z failed. http://url/to/verbose/html/page"

Comment 15

[Jesse Ruderman]

The comment could just be a link to TBPL:

* Without fully automated starring, a "permanent record" consisting of "40 successful 3 warning 0 failed" doesn't really tell me anything.  I have to visit TBPL and click around to see if any of the failures were new.

* It's easy to get from TBPL to hg.mozilla.org, to see exactly what was submitted.

* Once bug 631448 is fixed, it will be easy to get from TBPL to a download link as well.

Comment 16

[Zack Weinberg (:zwol)]

I want links directly to the logs for the failing jobs even if there is also a link to the TBPL summary for the push, because TBPL is still subject to odd failure modes along the lines of "gets stuck at 75% loaded forever", and is quite painfully slow if you go back too far.

I kinda wish the list of candidate known failures that TBPL generates were in the output of showlog.cgi.  I'd happily trade that feature for *everything* showlog.cgi currently does, by the way.

Comment 17

[Jesse Ruderman]

TBPL's single-push view has been reliable for me since http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/pushloghtml?changeset=fdf20aed8ef9.  There should be no "pain from going back too far" now.

TBPL doesn't deal well with Try resets, but I'd prefer we fixed that in TBPL than add mountains of spam to bugs as a workaround.

Comment 18

[Zack Weinberg (:zwol)]

I hope you will understand why, given the track record, I do not want to rely on Tinderbox, TBPL, or anything related to them, for this information.

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: try_bugposter v3

This script has been running in staging for a while and I've been checking the output.  Added handling for 404 errors, also retries for both posting to bugzilla and getting the json content from cruncher.

Right now the default behaviour is to look for '--post-to-bugzilla' in the syntax before trying to post to bugzilla.

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

This is now part of the larger project detailed here:     
http://crashopensource.blogspot.com/2011/05/assistedautomated-landing-designing.html
and here: https://wiki.mozilla.org/BugzillaAutoLanding

This should not only poll for completed try runs, but for anything with autoland-$bugnumber in the reason and post back to that bug

For try syntax, this tools should allow someone to use the syntax to 
a) include list of the bug(s) that they would like their try results posted to and 
b) turn off email notifications

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

Status update:  http://hg.mozilla.org/users/lsblakk_mozilla.com/tools/rev/9faf7b57e770 has my most recent work on this bug. I had tried to run it in production but quickly discovered a significant flaw in that the comments for a push *start* ok (bug number present and grabbed by the poller) but then once tests or talos show up the comment that is returned from the db is the more recent (and blank) comment from those builders which means that at the time of trying to send the results back to the bug there is no bug to report to.

I have made notes to myself and when I return from vacation on July 5th I will get back to writing tests for this and working out a solution.

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

Currently running on cruncher - have first bug post up: https://bugzilla.mozilla.org/show_bug.cgi?id=434998#c20

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: adds try_bugposting to try syntax options in trychooser webpage

Comment 24

[John Ford [:jhford] CET/CEST Berlin Time]

Comment on attachment 546664 [details] [diff] [review]
adds try_bugposting to try syntax options in trychooser webpage

^5

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 546664 [details] [diff] [review]
adds try_bugposting to try syntax options in trychooser webpage

http://hg.mozilla.org/build/tools/rev/3a37bcf60d20

Comment 26

[Lukas Blakk [:lsblakk] use ?needinfo]

This is currently running as a cronjob on cruncher:

*/10 * * * * source /home/lsblakk/autoland/bin/activate && cd /home/lsblakk/autoland/tools/scripts/autoland && time python schedulerDBpoller.py -b try -f -c schedulerdb_config.ini

which is running http://hg.mozilla.org/users/lsblakk_mozilla.com/tools/diff/2cf0d74bddde/scripts/autoland/schedulerDBpoller.py at the moment. 

While this is not "fixed", the functionality has been added to the try syntax helper page and developers have been informed through Twitter, blog post (planet), IRC, and as a choice on the syntax helper webpage that they can try it out. I will continue to monitor the performance of this script while also continuing to develop it as part of bug 657828.

When that code lands in our repos I will circle back to this to close.

Comment 27

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I used this yesterday, and it worked! :-)

One thing that the WebKit bots do that would be nice is to list the failing tests in the bug so it's clear if they're relevant or not without loading the log.

If this is something you'd prefer to do in a separate bug I can file one.

Comment 28

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #27)
> I used this yesterday, and it worked! :-)
> 
> One thing that the WebKit bots do that would be nice is to list the failing
> tests in the bug so it's clear if they're relevant or not without loading
> the log.
> 
> If this is something you'd prefer to do in a separate bug I can file one.

That's an option, and one I considered in the initial design. What can happen is that a ton of stuff fails and the bug comment gets very long.

One idea would be to add another flag for putting the buildernames (therefore which test/talos/build) failed into the comment, then if that comment is long - you asked for it :)

Or perhaps a threshold at which putting the names in the comment is not allowed? Some try runs can generate 200+ builder results.  Other ideas?

Comment 29

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #28)
> Or perhaps a threshold at which putting the names in the comment is not
> allowed? Some try runs can generate 200+ builder results.  Other ideas?

Just cut it off at N lines, for some reasonable N, say 25?

And I'm much less interested in "Linux debug mochitest-1 failed" than I am in "test-foo-api.html failed."

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

> And I'm much less interested in "Linux debug mochitest-1 failed" than I am
> in "test-foo-api.html failed."

In that case, that might be a separate bug since the "test-foo-api.html failed" is not available through the schedulerdb (the source of completed try builds with results) at this time.  I'll file a bug for that and in the meantime would having the buildername still help?

Comment 31

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #30)
> > And I'm much less interested in "Linux debug mochitest-1 failed" than I am
> > in "test-foo-api.html failed."
> 
> In that case, that might be a separate bug since the "test-foo-api.html
> failed" is not available through the schedulerdb (the source of completed
> try builds with results) at this time.  I'll file a bug for that and in the
> meantime would having the buildername still help?

I don't think the buildername is all that useful ... but others may disagree.

Comment 32

[Lukas Blakk [:lsblakk] use ?needinfo]

Examples from the 'wild':

https://bugzilla.mozilla.org/show_bug.cgi?id=574403#c10
https://bugzilla.mozilla.org/show_bug.cgi?id=574403#c12
https://bugzilla.mozilla.org/show_bug.cgi?id=669611#c12
https://bugzilla.mozilla.org/show_bug.cgi?id=646157#c42

Comment 33

[Zack Weinberg (:zwol)]

This isn't useful to me till the message added to the bug includes the URLs of all "error" and "warning"-state logs, for the reasons stated in comment 16.  (I still regularly find TBPL getting stuck at 75% loaded, especially if more than a day has elapsed since the push.)

The feature Kyle requested would sure be nice, but would not remove the need for direct links to the logs.

Comment 34

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Some of my Try builds are actually so other people can download a build and test the changes - eg, someone from UX (they'd like for us to do Try builds more often), or someone with a bug I can't reproduce locally, etc. 

In those cases, it's far more friendly to have a link to the download directory directly in the bug comment, rather than having to go through TBPL (where the link well is hidden).

Comment 35

[Lukas Blakk [:lsblakk] use ?needinfo]

> In those cases, it's far more friendly to have a link to the download
> directory directly in the bug comment

definitely easy to add that into the comment string, I'll can include it in the next round of improvements.

Comment 36

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #33)
> This isn't useful to me till the message added to the bug includes the URLs
> of all "error" and "warning"-state logs, for the reasons stated in comment
> 16.  (I still regularly find TBPL getting stuck at 75% loaded, especially if
> more than a day has elapsed since the push.)

so it sounds like two bugs here - one to do some non-trivial log parsing (which can be filed as a blocking bug to the try_enhancements tracking bug) and then something for that TBPL loading issue, I'm not sure what the cause is but sounds very frustrating.

Comment 37

[Jeff Hammel]

For log parsing, you might look at http://hg.mozilla.org/automation/logparser/ or talk to :jgriffin, though I agree that this should probably go as a separate bug.

Comment 38

[Lukas Blakk [:lsblakk] use ?needinfo]

> In those cases, it's far more friendly to have a link to the download
> directory directly in the bug comment, rather than having to go through TBPL
> (where the link well is hidden).

This is now live, so any future use of the --post-to-bugzilla flag will give an ftp link in the bug comment (this link will be broken after 4 days though until there's a fix on the moving of old try builds to /old is fixed)

Comment 39

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could we make the syntax here more human-author friendly? Something like:

--bug 675107

is a lot easier to remember and write than:

--post-to-bugzilla Bug 675107

Comment 40

[Mozilla RelEng Bot]

Try run for 21417b3e45d9 is complete.
Detailed breakdown of the results available here:
    http://tbpl.mozilla.org/?tree=Try&rev=21417b3e45d9
Results:
    success: 151
    warnings: 18
    failure: 3
Total buildrequests: 172
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-21417b3e45d9

Comment 41

[Robert Longson [:longsonr]]

I tried checking the checkbox and then entering a number but it doesn't fill in the number as you type. You have to uncheck and then recheck the box to get the bug number to be filled in in the syntax box.

Comment 42

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Robert Longson from comment #41)
> I tried checking the checkbox and then entering a number but it doesn't fill
> in the number as you type. You have to uncheck and then recheck the box to
> get the bug number to be filled in in the syntax box.

The code for the trychooser page lives here: http://hg.mozilla.org/build/tools/file/tip/trychooser  

If you have a better way to get the number into the syntax box, please submit a patch. What's there now is my best attempt at javascript as someone with very little experience with it so it's just "good enough".

Comment 43

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I expected https://tbpl.mozilla.org/?tree=Try&rev=4a1ca43eaef8 to result in a post to the bug, but it didn't; why it didn't isn't clear to me.

Comment 44

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to David Baron [:dbaron] from comment #43)
> I expected https://tbpl.mozilla.org/?tree=Try&rev=4a1ca43eaef8 to result in
> a post to the bug, but it didn't; why it didn't isn't clear to me.

Logs show the bug number was not picked up in the bug_commenting script, it's not obvious to me as to why. I will try to reproduce this in tests as this script is still in active development. thanks for letting me know about this anomaly.

Comment 45

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: big patch for posting to bug when builds are complete

This is my first attempt to parcel out some of the review process for what is currently running and posting to bugs (and has been since mid-August) but it's also part of the larger Autolanding system modules.  So I stripped out everything that wasn't needed by schedulerDBpoller to run the tests and to work on cruncher.

This script is currently running as a cronjob on cruncher and posts to bugs, you can see the bugs it has posted to by looking at /home/lsblakk/autoland/tools-new/scripts/autoland/postedbugs.log

I'd like to find a way to land the schedulerDBpoller-relevant stuff so that future landings for Autoland components (Tracking bug 657828) will be slightly easier.

If it helps with the binaries for the .sqlite files, this same patch is also up at my user repo: http://hg.mozilla.org/users/lsblakk_mozilla.com/tools/file/948b7a3122d5/scripts/autoland

Comment 46

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: big patch for posting to bug when builds are complete

Most recent version, with more fixes and cleanups than previously.  This is still running live on cruncher and posting to bugs - logs are viewable in /home/lsblakk/autoland-2.6/tools/scripts/autoland

Comment 47

[Nick Thomas [:nthomas] (UTC+12)]

I had to disable the cronjob on cruncher for repeated comments, see bug 629668 comment #29 through to 34. Also bug 534963 and bug 704855 since Friday night, according to .../scripts/autoland/postedbugs.log.

Comment 48

[Serge Gautherie (:sgautherie)]

5 identical comments :
https://bugzilla.mozilla.org/show_bug.cgi?id=694353#c12 to 16, 05-10 seconds apart.

Comment 49

[Lukas Blakk [:lsblakk] use ?needinfo]

This is now landed as part of autoland: http://hg.mozilla.org/build/autoland/file/tip/schedulerDBpoller.py and this functionality has been available to developers since August 2011. Resolving.


Docs: https://wiki.mozilla.org/Build:Autoland
      https://intranet.mozilla.org/RelEngWiki/index.php/How_To/Administrate_Autoland

Comment 50

[Andrew Quartey [:drexler]]

I pushed a job to Try and upon completion the results weren't posted to the bug. 
Here's the url: https://tbpl.mozilla.org/?tree=Try&rev=a2dbbd179b6b