Fix issue with stale cache from bad builds.

Fix issue with stale cache from bad builds.

We always want to re-build packages we are revving, however, if the last
build succeeds in building but fails tests, we have a bad local cache that
has revved packages.  This avoids this issue by working on all packages we
are revving.

Change-Id: I3bd7463a4090b1f007d09be81bdf65657bd9c3f3

BUG=7589
TEST=Ran it with cbuildbot.

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=365d4b0

[sosa, 2010-10-15 04:10:23]

Fix for the builders to always build packages we're revving from source.

[David James, 2010-10-15 04:42:08]

http://codereview.chromium.org/3745006/diff/6001/7002
File cros_mark_all_as_stable (right):

http://codereview.chromium.org/3745006/diff/6001/7002#newcode99
cros_mark_all_as_stable:99: ./cros_workon start ${PACKAGE_LIST}
If any packages are started using cros_workon, cros_mark_as_stable will rev the
wrong package. It rev's the 9999 package instead of rev'ing the stable package
:(

This needs to be moved after the cros_mark_as_stable call. We should also
ideally update both this script and cros_mark_as_stable to report an error if
there are any packages in $(cros_workon list).

Alternatively, take a look at my patch avoids using equery-BOARD and solves this
problem: http://codereview.chromium.org/3798003

If that patch lands there's no need to do any checking for $(cros_workon list)
because we avoid usage of equery-BOARD altogether.

http://codereview.chromium.org/3745006/diff/6001/7003
File cros_mark_as_stable.py (right):

http://codereview.chromium.org/3745006/diff/6001/7003#newcode127
cros_mark_as_stable.py:127: gflags.FLAGS))
Looks like this is an unnecessary change.

[sosa, 2010-10-15 17:08:20]

http://codereview.chromium.org/3745006/diff/6001/7002
File cros_mark_all_as_stable (right):

http://codereview.chromium.org/3745006/diff/6001/7002#newcode99
cros_mark_all_as_stable:99: ./cros_workon start ${PACKAGE_LIST}
Thanks I'm going to temporarily push this while yours goes through review since
this is affecting our tree closure atm

On 2010/10/15 04:42:08, David James wrote:
> If any packages are started using cros_workon, cros_mark_as_stable will rev
the
> wrong package. It rev's the 9999 package instead of rev'ing the stable package
> :(
> 
> This needs to be moved after the cros_mark_as_stable call. We should also
> ideally update both this script and cros_mark_as_stable to report an error if
> there are any packages in $(cros_workon list).
> 
> Alternatively, take a look at my patch avoids using equery-BOARD and solves
this
> problem: http://codereview.chromium.org/3798003
> 
> If that patch lands there's no need to do any checking for $(cros_workon list)
> because we avoid usage of equery-BOARD altogether.
>