If the option is specified, the utility will pipe the test stdout/stderr
to separate files and dump them at the end.
BUG=8585
TEST=./bin/cros_run_parallel_vm_tests suite_Smoke suite_Smoke --order_output
Change-Id: I6c4fcb02456441b4e4fc3f1717cdb5d607d733b9
Review URL: http://codereview.chromium.org/4422001
The developer script runner did not pad for the trailing
GPT header and using a full-sized kernel image extracted
from a build image resulted in failure. This change
accomodates for that and warns when an error occurs.
TEST=used a dd'd over kernel image and it worked
BUG=chromium-os:7451
Change-Id: I8efd7fbb92fe4d5a3c715580f8c21e52c21957c9
Review URL: http://codereview.chromium.org/4418001
(cherry picked from commit 5f928bef4eb551b94fcc45821eee71aa206cef86)
Review URL: http://codereview.chromium.org/4417002
This allows the user to specify a custom results directory root. cbuildbot can
be switched to use cros_run_parallel_vm_tests if necessary without any further
changes.
Also create parents directories for user-specified results directory roots in
run_remote_tests.
BUG=8585
TEST=./bin/cros_run_parallel_vm_tests suite_Smoke suite_Smoke \
--results_dir_root=/tmp/foo
Change-Id: I7314c1d9e74ca139eaa4bd95290866a43a3606ff
Review URL: http://codereview.chromium.org/4297003
When you pass '--foo="bar baz"' to a script, the argument is literally
passed as "bar baz", with the quotes. So we need to not add unnecessary
quotes in there.
When enter_chroot.sh parses arguments, it actually removes the quotes
for you, and splits up arguments. As a result, it may actually
be necessary to (1) use the above broken syntax when you call scripts
using enter_chroot.sh; but (2) don't use that syntax when calling
scripts without enter_chroot.sh. That's a broken situation, so I've
added a TODO for that. I've also added more warnings to
cros_mark_as_stable.py so that it's easier to debug when it doesn't
work.
BUG=chromium-os:8633
TEST=Ran unit tests. Planning to watch TOT buildbot post-commit to make sure behavior is right.
Change-Id: Ia1a0e60153fec60cb7ed4db2da128ffd9ae81e23
Review URL: http://codereview.chromium.org/4385002
Current usage is simple: just specify a list of tests and each one will be run
on a separate VM using the latest image on a default board. Exit code is
non-zero if any of the tests fail. Output from separate tests is interleaved.
More CLs to follow -- specifying a result directory, non-interleaved output,
base ssh port, board, image path, etc.
BUG=8585
TEST=./bin/cros_run_parallel_vm_tests suite_Smoke suite_Smoke
Change-Id: Ifa3396768050905ec02e4cad8b8f065a6d129154
Review URL: http://codereview.chromium.org/4337003
Currently works around issue till we get a good fix in for 9.x.
Change-Id: I9c7225508fa8f46a5fa5e0b41abc4e373cc80085
BUG=8606
TEST=Tested by sending SEGV to a delta update during update and saw it successfully fall back to a full update and succeed.
Review URL: http://codereview.chromium.org/4258002
2. Source shflags, if they are in the current directory
Change-Id: Id22e597a6fb71905f2d0ca5c4a1d94ce5a8a931f
Review URL: http://codereview.chromium.org/4177005
Currently, if a build is slow, you only get debug output after an hour.
This is to allow for uncluttered output. If output is too cluttered, it's hard
to distinguish regular output from errors.
The problem with this approach is that it's often hard to debug why the build
is slow. Now that Chrome builds by default, it takes over an hour to build,
and people see little indication as to why. You can show the output with
build_packages --showoutput, but that is often too verbose and clutters the
output too much.
Here's an example log snippet that is hard to debug:
Pending 2, Ready 0, Running 1, Retrying 0, Total 22 [Time 5m20.5s Load 3.69 3.04 2.66]
Pending 2, Ready 0, Running 1, Retrying 0, Total 22 [Time 5m25.5s Load 3.40 2.99 2.65]
... yada yada yada ...
Pending 2, Ready 0, Running 1, Retrying 0, Total 22 [Time 45m32.9s Load 1.00 1.18 2.95]
From the above output, we see that a package is building for a long time, but
we don't know what package. We should output the package name every two minutes
at least so people know what package is taking so long. That's what this change
implements.
BUG=chromium-os:8575
TEST=Confirmed new status appear for regular build_packages. Confirmed
build_packages --showoutput is unchanged.
Change-Id: Ie18b23ac7a8a6e2c24b43ec3691606c7da5e43cb
Review URL: http://codereview.chromium.org/4318003
chromeos-chrome has mostly self-contained dependencies, so there usually
isn't need to rebuild it just because a dependency changed. This allows for
us to use the binaries for chromeos-chrome more often.
BUG=chromium-os:8394
TEST=Check that chrome doesn't rebuild with
./parallel_emerge -gp --workon=libcros --board=x86-generic
chromeos-chrome
Change-Id: Ifa14c890917991a8d11f1f0e757f28686d611a72
Review URL: http://codereview.chromium.org/4243003
BUG=not sure, but this is CL 2/2 to fix broken L13 build
TEST=tested usb intall/auto update
Change-Id: I14cdd1ec941a0653ac25ec7ef72f69f2ec8f64c9
Review URL: http://codereview.chromium.org/4270002
BUG=chromium-os:8493
TEST=Ran unit tests. Verified that cros_mark_as_stable.py supports
running on just the private or public overlay.
Change-Id: I5e2e8fc5e63b3c93bb688a5ce87233315c0c2d1c
Review URL: http://codereview.chromium.org/4250001
You can access this by passing:
--tracker-user="user@chromium.org"
--tracker-passfile="fileContainingPassword"
...to access anonymously, just set --tracker-user=""
...if you don't include the --tracker-user option, we won't try to
fetch priority/milestone.
To use this feature, you need the GData library. Until we get that
put in hard-host-depends, the script will simply print instructions
for installing GData if it detects that you don't have it.
At the moment, I believe that logging in isn't giving you any extra
access. Therefore, any bugs that don't allow anonymous access will
not show their priority/milestone. I am working on figuring out what
the problem is there.
Change-Id: If388c20c43ee2fb0c1ab8f748ffea65e354eeb1e
BUG=chromium-os:8205
TEST=Ran ./cros_changelog 0.9.104.0 --tracker-user="" and verified that some bugs got priority/milestone.
Review URL: http://codereview.chromium.org/4102013
This is being remounted ro in cros_make_image_bootable so I should be checking
for the stateful mount pt not the rootfs mountpt
Change-Id: I1ee64489516fae10a6246c5d79236c8b5df090ee
BUG=8116
TEST=Ran it and ran bin/cros_start vm and inspected /usr/local
Review URL: http://codereview.chromium.org/4148013
is abused throughout the script and this is where end up at when prebuilt
is called
BUG=8389
TEST=Ran from the directory archive_build actually runs from.
Review URL: http://codereview.chromium.org/4119017
BUG=8306
TEST=Ran au_test_harness with CL for adding vm option for the devserver on the last channel release and my TOT. All tests passed.
Review URL: http://codereview.chromium.org/4165009
Change-Id: Ia2ce305dff2911dc4008d5f6e383535e4bbd4ab0
Enabled host prebuilt upload on the x86-generic target.
BUG=NA
TEST=Tested on an x86-generic build to ensure it uploads as expected
Review URL: http://codereview.chromium.org/4128014
Change-Id: Iabc931f2eb1751ca9d05e92e64e5361755791648
BUG=
TEST=Copied and pasted from other try/except
Review URL: http://codereview.chromium.org/4109006
Other changes:
1. Clean up revision handling to be more forgiving if people want to use
things that don't start with "cros/". Instead, we only enforce that
people use tags if they want to use the one-argument version of
cros_changelog.
2. Tags are quoted in the command-line so that people can, for instance,
diff 'cros/master{2 days ago}' vs 'cros/master{1 day ago}'.
Change-Id: I28c7d77ae83256d4c28411ef589f3e726cc81d80
BUG=chromium-os:8205
TEST=Ran ( ./cros_changelog 0.9.104.0 cros/master > /tmp/test1.html &&
./cros_changelog --sort-by-date 0.9.104.0 cros/master > /tmp/test2.html )
Both commands print changes between 0.9.104.0 and master, but the second command prints results sorted by date.
Review URL: http://codereview.chromium.org/4130009
