My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 209442: Reduce number of symbol uploads in buildbots
1 person starred this issue and may be notified of changes. Back to list
 
Project Member Reported by mkr...@chromium.org, Feb 17, 2012
We recently got word from the Crash Team that Chrome OS was sometimes uploading too many symbol files, causing us to trigger DoS protections.

eblake@ modified his cron jobs to spread out symbol uploads for now, but this will presumably come up again as an issue when we upload symbols directly from the buildbots.

We currently upload _all_ the symbol files.  In a recent build, this was 2100+ symbol files.  According to the Crash Team 95+% of the uploaded symbols were duplicates, and the number of connections is the issue, not the payload (so doing a query first to check if a duplicate won't help).

Mar 17, 2013
#1 bugdro...@chromium.org
(No comment was entered for this change.)
Blocking: chromium-os:25731 chromium-os:25731
Feb 17, 2012
#2 mkr...@chromium.org
(No comment was entered for this change.)
Blocking: 25731
Feb 17, 2012
#3 mkr...@chromium.org
Offhand, it seems to me we could have each buildbot remember what symbol files it uploaded and then not try to upload any duplicates.  I hate the idea of there being state across builds, but this would otherwise seem relatively easy to implement.  A hash is already calculated for symbol files, and so we would only have to track that instead of keeping around the actual symbol files.  In addition I feel the most likely scenario is that, from build to build, most symbol files aren't changing, so we would only really need to track symbol hashes from the previous build.  I.e. There wouldn't be much benefit to trying to avoid uploading a duplicate from three builds ago that was _not_ a duplicate from the previous build.

Owner: davidjames@chromium.org
Feb 21, 2012
#4 eblake@google.com
Maybe just store the hashes in google storage next to the 900 MB+ debug.tgz file. The buildbot would retrieve the previous builds hashes from big store and not have to worry about maintaining state itself.
Feb 28, 2012
#5 davidjames@chromium.org
What if the upload symbols script just sleep for 200ms or so in between uploads to prevent too many connections from happening per second? If the uploads are slower, that's fine because we have other stuff that can happen in parallel.
Status: Assigned
Owner: mkr...@chromium.org
Feb 29, 2012
#6 eblake@chromium.org
There are 12 canary,  5 R18,  7 R17, and 5 release stabilize builders (29) that will all run the symbol upload step.  I currently expect the number of builders to continue increasing for all channels. The builds are staggered such that beta/stable share physical hosts, dev/canary is 4x day.
Apr 3, 2012
#7 mkr...@chromium.org
There's a CL at https://gerrit.chromium.org/gerrit/19566 to add the 200ms sleep in between symbol uploads.  Now that symbols are being uploaded by the buildbots, we'll see if this becomes necessary.

Labels: Iteration-53
Apr 25, 2012
#8 mkr...@chromium.org
The Crash Team reported that some symbol uploads were blocked today due to the DoS protections.  eblake@ suggested I commit the CL to add a delay, since I'll be out on paternity leave for a week, and the changes for  issue 25731  haven't been merged back to the branches yet.  Hopefully, this will reduce the likelihood of blockage.

Cc: r...@chromium.org su...@chromium.org
Labels: Iteration-54
Apr 25, 2012
#9 mkr...@chromium.org

commit dc7b317587601d35bd278804c767f3d88dd17aa4
Author: Michael Krebs <mkrebs@chromium.org>
Date:   Tue Apr 3 18:10:31 2012 -0700

    scripts: Sleep for 200ms between symbol uploads
    
    To avoid looking like we're DoS'ing the symbol server, force a delay between
    symbol uploads.  If this becomes a bottleneck for buildbots, this should be
    modified to only upload symbol files that have changed, by checking against
    the buildbot's previous debug.tgz.
    
    BUG=chromium-os:26596
    TEST=Manually ran upload_symbols against staging symbol server
    
    Change-Id: Iecf11e26a70f0c44838fb13e2ebc6ebb78336c50
    Reviewed-on: https://gerrit.chromium.org/gerrit/19566
    Commit-Ready: Michael Krebs <mkrebs@chromium.org>
    Reviewed-by: Michael Krebs <mkrebs@chromium.org>
    Tested-by: Michael Krebs <mkrebs@chromium.org>

M       upload_symbols

May 8, 2012
#10 bugdro...@chromium.org
Commit: dc7b317587601d35bd278804c767f3d88dd17aa4
 Email: mkrebs@chromium.org

scripts: Sleep for 200ms between symbol uploads

To avoid looking like we're DoS'ing the symbol server, force a delay between
symbol uploads.  If this becomes a bottleneck for buildbots, this should be
modified to only upload symbol files that have changed, by checking against
the buildbot's previous debug.tgz.

BUG=chromium-os:26596
TEST=Manually ran upload_symbols against staging symbol server

Change-Id: Iecf11e26a70f0c44838fb13e2ebc6ebb78336c50
Reviewed-on: https://gerrit.chromium.org/gerrit/19566
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
Reviewed-by: Michael Krebs <mkrebs@chromium.org>
Tested-by: Michael Krebs <mkrebs@chromium.org>

M	upload_symbols
Jul 23, 2012
#11 mkr...@chromium.org
(No comment was entered for this change.)
Blocking: chromium-os:25731
Nov 8, 2012
#12 d...@google.com
(No comment was entered for this change.)
Cc: -d...@chromium.org
Blocking: -chromium-os:25731
Mar 6, 2013
#13 lafo...@google.com
(No comment was entered for this change.)
Labels: OS-Chrome
Mar 9, 2013
#14 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Build Build
May 30, 2013
#15 vapier@chromium.org
i've been thinking about this of late.  rather than doing it on a per-bot basis, sharing state in google storage makes sense (since we often share things across arches or base boards).

i think a simple schema like this should work (semi-pseudo code just to convey idea, not exact implementation details):
 - before uploading anything, run once:
   cached_files=$(gsutil ls gs://chromeos-manifest-versions/breakpad-symbols/)
 - before uploading a symbol, do:
   if has $hash ${cached_files[@]}; then
     if prev_filesize=$(gsutil cat gs://chromeos-manifest-versions/breakpad-symbols/$hash); then
       if [ $prev_filesize -eq $filesize ]; then
         return # symbol already uploaded
       fi
     fi
   fi
 - after uploading a symbol, do:
   echo $filesize > $hash
   gsutil cp $hash gs://chromeos-manifest-versions/breakpad-symbols/$hash
 - have a process somewhere (a dedicated bot, or perhaps use spare idle cycles on an arm paladin that doesn't run hwtests) that looks at the timestamps of all files in gs://chromeos-manifest-versions/breakpad-symbols/ and deletes ones older than say 30 days (and on a per-file basis, add a random [1, 15] number of days so that we don't expire all files at once).

since the crash server can handle re-uploading the same symbol file, we don't have to worry about google storage flakiness or consistency issues.  and with python multiprocessing/queues, it should be easy to set up a process that handles uploading in the background while the main process does the collision detection.

i'm not sure the filesize checking is even needed as i'm not sure hash collisions ever really occur (or at least, on a scale where we care).  i'll have to check with the crash docs/team to see what makes an upload unique and how symbol resolution happens.

thoughts ?
Owner: vapier@chromium.org
Cc: -eblake@chromium.org
May 30, 2013
#16 vapier@chromium.org
+a build team members to get their feedback
Cc: r...@chromium.org mtennant@chromium.org mer...@chromium.org petermayo@chromium.org sosa@chromium.org
Labels: Build-Tools-Chromite Cr-Internals-Logging
May 31, 2013
#17 davidjames@chromium.org
+1 to vapier's suggestion

+1 to vapier's suggestion, although I'm not sure about the process adding a random [1,15] number of days

Besides vapier's suggestion, I'd also suggest we implement a global limit on how many processes talk to Google Storage in parallel. The reason we have the 200ms sleep and one process isn't because Google Storage actually requires we wait 200ms -- it's just because we have a lot of bots and with the number of bots we have it adds up to a lot of requests going to Google Storage. As we add more bots, it's going to eventually add up to too many requests to the crash server and we're going to need to bump up that delay again. If we use a global number then we'll won't have to hardcode a delay.
Labels: -Sev-2 -Iteration-53 -Iteration-54 -Build
May 31, 2013
#18 vapier@chromium.org
when you say "Google Storage", i think you mean "Crash Server" ?  the 200ms sleep is only for talking to the crash server so we don't trigger their automatic DoS logic.  i'm not aware of sleeps we have in place to limit Google Storage communication.

with this in place, i'm not sure if we still need the 200ms sleep as the number of requests should go down significantly.  although it probably doesn't matter as long as this step is run in parallel with other things (like vm/hw tests).
Jun 4, 2013
#19 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 167d83eb8e61346b88c70361acc9cdbf37362493

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : I83ac1aa73f98f72c6a8d3a909f4b649059faf98e
Reviewed-at   : https://gerrit.chromium.org/gerrit/57182

parallel: BackgroundTaskRunner: pass down args/kwargs to tasks

In order to use fun multiprocessing objects like Value and Queue, you have
to serialize the objects sooner rather than later.  That means you can't
do something perfectly reasonable like:
	results = multiprocessing.Queue()
	with parallel.BackgroundTaskRunner(myfunc) as queue:
		for x in (1, 2, 3):
			queue.put((results, x))

Python will crap itself like so:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/queues.py", line 266, in _feed
    send(obj)
  File "/usr/lib64/python2.7/multiprocessing/queues.py", line 77, in __getstate__
    assert_spawning(self)
  File "/usr/lib64/python2.7/multiprocessing/forking.py", line 51, in assert_spawning
    ' through inheritance' % type(self).__name__
RuntimeError: Queue objects should only be shared between processes through inheritance

In order to pass that results queue down to myfunc, you have to include it
in the multiprocess.Process() initialization.  Unfortunately, our current
framework does not support passing args/kwargs at that phase.

So let's throw in the plumbing to support arbitrary passing of args and
kwargs down to the function at task creation time.  Not only does this
solve the above problem, but it makes implementations cleaner when you
have a set of args/kwargs that are common to all calls as you no longer
need to manually add them to the queue.

Thus the aforementioned snippet now becomes:
	results = multiprocessing.Queue()
	with parallel.BackgroundTaskRunner(myfunc, results) as queue:
		for x in (1, 2, 3):
			queue.put((x,))

BUG=chromium:209442
BUG=chromium:213204
TEST=`lib/parallel_unittest.py` passes
TEST=my new code that needs this functionality works

Commit-Queue: Mike Frysinger <vapier@chromium.org>

M  lib/parallel.py
M  lib/parallel_unittest.py
Jun 13, 2013
#20 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : f08736999b3fbb4e2f14cdc70a8613f3fa270bf0

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : I068b81b648d7c829345b069c57c4ff644e0b1d52
Reviewed-at   : https://gerrit.chromium.org/gerrit/57188

upload_symbols: rewrite in python

We want to do more stuff with upload_symbols.  The current bash code is
limiting us though.  Rewrite it in python and use chromite libraries.

BUG=chromium:209442
BUG=chromium:213204
TEST=`./buildbot/run_tests` passes
CQ-DEPEND=CL:57182

Commit-Queue: Mike Frysinger <vapier@chromium.org>

A  bin/upload_symbols
M  buildbot/cbuildbot_commands.py
A  scripts/upload_symbols.py
A  scripts/upload_symbols_unittest.py
Jun 17, 2013
#21 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : d6a4c7e0ee4d53ddc5238dbddfc0417796a70e54

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : I18156e6e9cf1c886c6382944409573a9ed93455b
Reviewed-at   : https://gerrit.chromium.org/gerrit/58624

cbuildbot: simplify running chromite commands

Rather than make every helper command that runs a program in chromite
figure things out, add a keyword to _RunBuildScript to centralize it.

BUG=chromium:209442
BUG=chromium:213204
TEST=`./buildbot/run_tests` passes

Commit-Queue: Mike Frysinger <vapier@chromium.org>

M  buildbot/cbuildbot_commands.py
Jun 25, 2013
#22 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : d5fcb3af8a92306c70c098fe2c7c6ae90af1acda

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : Ib10cb9c48bf2bf6f06a7b0400af4b1fe54ede856
Reviewed-at   : https://gerrit.chromium.org/gerrit/58625

upload_symbols: rewrite in python

We want to do more stuff with upload_symbols.  The current bash code is
limiting us though.  Rewrite it in python and use chromite libraries.

BUG=chromium:209442
BUG=chromium:213204
TEST=`./buildbot/run_tests` passes
CQ-DEPEND=CL:57182

Commit-Queue: Mike Frysinger <vapier@chromium.org>

A  bin/upload_symbols
M  buildbot/cbuildbot_commands.py
A  scripts/upload_symbols.py
A  scripts/upload_symbols_unittest.py
Jun 26, 2013
#23 bugdro...@chromium.org
Project: chromiumos/platform/crosutils
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 830d853752480283795fe337a7319f0ca3aa2b35

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : I2157a5d47846783da297cfb0a3a8e8a709ab55a0
Reviewed-at   : https://gerrit.chromium.org/gerrit/57189

upload_symbols: delete

This has been rewritten in python and moved to chromite.

BUG=chromium:209442
BUG=chromium:213204
TEST=None
CQ-DEPEND=CL:57188

Commit-Queue: Mike Frysinger <vapier@chromium.org>

D  upload_symbols
Jun 26, 2013
#24 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 56829b36f676044c477408b1c064901700bcc1f3

Code Review +2: David James
Verified    +1: Mike Frysinger
Change-Id     : I7b67dd4b06f113f9dc4b315289134233491ccf1c
Reviewed-at   : https://gerrit.chromium.org/gerrit/58626

cbuildbot: run UploadSymbols for debug/trybots

At the moment, the only time UploadSymbols runs is on actual canaries.
We have it disabled for every other situation.  This means we do not
get the kind of testing we really need.

For remote trybots, still run this code, but limit ourselves to one
symbol to the staging server.  We've talked to the crash team and they
are OK with this as the load will be small.

BUG=chromium:209442
BUG=chromium:213204
TEST=`./buildbot/run_tests` passes

Commit-Queue: Mike Frysinger <vapier@chromium.org>

M  buildbot/cbuildbot_commands.py
M  buildbot/cbuildbot_commands_unittest.py
M  buildbot/cbuildbot_config.py
M  buildbot/cbuildbot_stages.py
Aug 2, 2013
#25 scottz@chromium.org
Fixed?
Labels: -Build-Tools-Chromite Build-Tools
Aug 2, 2013
#26 vapier@chromium.org
no, just much closer to being a reality since upload_symbols is written in python now.  the real meat of this bug still needs implementing -- communication with other bots/builds so that the same symbol doesn't get uploaded.
Jan 8, 2014
#27 scottz@chromium.org
(No comment was entered for this change.)
Labels: fixit
Feb 13, 2014
#28 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : d385bc64eb0230f1c5c2a950bc72c8285b8ddd43

Code-Review  0 : David James, Matt Tennant, Yu-Ju Hong, chrome-internal-fetch
Code-Review  +2: Mike Frysinger
Commit-Queue 0 : David James, Matt Tennant, Yu-Ju Hong, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, Matt Tennant, Yu-Ju Hong, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : Ia74a7a119604f9ff64857e3366b612f092a1330f
Reviewed-at    : https://chromium-review.googlesource.com/186050

cros_build_lib: new Collection helper

This is like collections.namedtuple, but produces an object with mutable
members.

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes

lib/cros_build_lib.py
lib/cros_build_lib_unittest.py
Feb 14, 2014
#29 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 8ec8c50abc3c1d1980920539ebe69c0b01d8d7ba

Code-Review  0 : David James, Matt Tennant, Mike Frysinger, chrome-internal-fetch
Code-Review  +2: Yu-Ju Hong
Commit-Queue 0 : David James, Matt Tennant, Yu-Ju Hong, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, Matt Tennant, Yu-Ju Hong, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : I48133b2a295233b8dcacf02c48ffa3cb2f82a2b7
Reviewed-at    : https://chromium-review.googlesource.com/185623

upload_symbols: add some basic upload stats

Log the number of symbols we uploaded and how long the overall process
took.  This is useful when triaging and gathering data after the fact.

This also renames the developer-only --upload-count to --upload-limit
so that the names stay consistent.  I'm probably the only one who uses
this flag, so it won't impact people.

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes
TEST=`upload_symbols foo.sym` final log line looks good

scripts/upload_symbols.py
scripts/upload_symbols_unittest.py
Feb 14, 2014
#30 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 319cc329e6d2575f4941a7ef6714e46d34500d65

Code-Review  +2: Mike Frysinger
Verified     +1: Mike Frysinger
Commit Queue   : Chumped
Change-Id      : I2c97e4ecd1007c32c5472ae2ed6b25b87504d4fd
Reviewed-at    : https://chromium-review.googlesource.com/186721

cbuildbot: update UploadSymbols call path

The UploadSymbols func renamed its arg from upload_count to upload_limit.

BUG=chromium:209442
TEST=`./buildbot/run_tests`

buildbot/cbuildbot_commands.py
buildbot/cbuildbot_commands_unittest.py
Feb 24, 2014
#31 bugdro...@chromium.org
Project: chromeos/manifest-internal
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : b02b840448c545549f7f541fa458398e474ac4aa

Code-Review  0 : Ben Henry, David James, Gaurav Shah, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Code-Review  +2: Mike Frysinger
Commit-Queue 0 : Ben Henry, David James, Gaurav Shah, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : Ben Henry, David James, Gaurav Shah, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : I6b9ba8d1233890c8e1f478fd21d5cffa799aeb4f
Reviewed-at    : https://chrome-internal-review.googlesource.com/154126

add swarming.client repo

Needed for chromite upload_symbols dedupe logic.

BUG=chromium:209442
TEST=None

full.xml
Feb 24, 2014
#32 bugdro...@chromium.org
Project: chromiumos/manifest
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 0efd3c6e2fe16f949049d6b40202c30164b965cc

Code-Review  0 : Ben Henry, David James, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Code-Review  +2: Mike Frysinger
Commit-Queue 0 : Ben Henry, David James, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : Ben Henry, David James, Matt Tennant, Vadim Shtayura, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : I6b9ba8d1233890c8e1f478fd21d5cffa799aeb4f
Reviewed-at    : https://chromium-review.googlesource.com/185621

add swarming.client repo

Needed for chromite upload_symbols dedupe logic.

BUG=chromium:209442
TEST=None

full.xml
Mar 14, 2014
#33 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : d42e5f0e9c97d24943511f755549cb94fd1a061d

Code-Review  0 : Mike Frysinger, chrome-internal-fetch
Code-Review  +2: David James
Commit-Queue 0 : David James, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : If2e625c8b42ef0f2e5136b4ba0825fa06f0b1cd2
Reviewed-at    : https://chromium-review.googlesource.com/190013

upload_symbols: fix dedupe counting

Rather than just break right away, finish processing all the results from
the query server.  This will be slightly slower (still <1 sec), but it'll
fix the confusing dedupe display we see today:

$ upload_symbols --yes --testing --upload-limit 1 --board x86-alex --dedupe
...
16:38:55: INFO: uploaded 1 symbols (3918 were deduped) which took: 0:11:22.169245

But we didn't dedupe 3918 symbols, we skipped them.

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes
TEST=`cbuildbot daisy-release` stats look OK
TEST=upload_symbols w/limit stats look OK

scripts/upload_symbols.py
Mar 14, 2014
#34 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 13870082fd55e6817e545e036374bbc3c345090d

Code-Review  0 : Mike Frysinger, chrome-internal-fetch
Code-Review  +2: David James
Commit-Queue 0 : David James, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : I3ed8b5a9558f56a1aca25d9e0c8b756b5fa2e7f5
Reviewed-at    : https://chromium-review.googlesource.com/190024

upload_symbols: make sure to always spin down notify process

If an exception is thrown in the main upload loop for any reason, we never
call join on the process we spawned.  This means UploadSymbols will hang.
Put that into a finally block to avoid that.

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes

scripts/upload_symbols.py
Mar 15, 2014
#35 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : 1010a89d3035f92de98e909bce0e9fb5b3a1e09d

Code-Review  0 : Mike Frysinger, chrome-internal-fetch
Code-Review  +2: David James, Don Garrett
Commit-Queue 0 : David James, Don Garrett, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, Don Garrett, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : I5a9c26da59a488898e0d8e664a0ac5d5b303cb01
Reviewed-at    : https://chromium-review.googlesource.com/190025

upload_symbols: avoid talking to dedupe server w/upload limit

The current code relies on _Upload not doing any where when the upload
limit is reached, but when deduping is enabled, that ends up not being
the case.  Instead, we end up querying the server one symbol at a time
which slows us down significantly.

Add an additional check to the main loop so we break out of the process
when our limit is hit rather than continuing to feed _Upload.

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes
TEST=`cbuildbot daisy-release` works

scripts/upload_symbols.py
Mar 17, 2014
#36 bugdro...@chromium.org
Project: chromiumos/chromite
Branch : master
Author : Mike Frysinger <vapier@chromium.org>
Commit : bbb594bee0ad61c67ff960ce7641750324c07211

Code-Review  0 : David James, Mike Frysinger, chrome-internal-fetch
Code-Review  +2: Don Garrett
Commit-Queue 0 : David James, Don Garrett, chrome-internal-fetch
Commit-Queue +1: Mike Frysinger
Verified     0 : David James, Don Garrett, chrome-internal-fetch
Verified     +1: Mike Frysinger
Change-Id      : Ic95c910608ed27a3523ed32713fd81b2ae2a50ab
Reviewed-at    : https://chromium-review.googlesource.com/186381

cbuildbot: enable deduping of uploaded symbols

BUG=chromium:209442
TEST=`./buildbot/run_tests` passes
TEST=`cbuildbot daisy-release` works (checked upload symbols stage)
CQ-DEPEND=CL:185622

buildbot/cbuildbot_commands.py
Mar 18, 2014
#37 vapier@chromium.org
the dedupe logic is live and working (albeit not as well as originally hoped).  follow up issues/ideas are being tracked in  issue 353461 .
Status: Fixed
Cc: -r...@chromium.org -r...@chromium.org -mtennant@chromium.org -mer...@chromium.org
Labels: -fixit Iteration-101 Iteration-102
Blockedon: chromium:353461
Mar 25, 2014
#38 kr...@chromium.org
(No comment was entered for this change.)
Status: Verified
Sign in to add a comment

Powered by Google Project Hosting