While setting up a Chromium repo on a new machine I ended up with a
missing .gclient_entries file. This triggered a warning message but it
led me in the wrong direction. I think that the new message - saying
exactly what problem was detected - will be slightly more helpful.
Change-Id: I8c91861f843e3d30881b1b4933a02ad966c114ef
Reviewed-on: https://chromium-review.googlesource.com/533314
Reviewed-by: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
This makes it possible to run hooks properly
in flattened DEPS.
Bug: 570091
Change-Id: If8175a57ebe8f607bd4ac83d4a26dcc4cc18165c
Reviewed-on: https://chromium-review.googlesource.com/535476
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
This will be useful e.g. to add cwd support for flatten.
No intended behavior change.
Bug: 570091
Change-Id: I014f97739676d55f6d5b37c10afd9221b1d0978d
Reviewed-on: https://chromium-review.googlesource.com/534193
Commit-Queue: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
It's unused, and not covered by tests.
See https://codereview.chromium.org/9232068/ where it was added ~5 years ago
for an abandoned project to convert to repo.
Bug: 570091
Change-Id: Ica59cd3b28f92e05607203218cbeb92a377ec99a
Reviewed-on: https://chromium-review.googlesource.com/534313
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
The second preview of VS 2017 Update 3 removed the MFC DLLs from the
redist directory. Luckily it appears that we don't actually need them.
The directories were also renamed from VC150 to VC141. This change
switches to VC* to make it more robust, enabled by the use of glob added
a few changes ago.
crrev.com/2938453003, which tests a package that was created with this
updated script, passed.
BUG=683729
R=scottmg@chromium.org
Change-Id: I4ae5dec949d16a83e1751e3d2ff7bd10a78b680f
Reviewed-on: https://chromium-review.googlesource.com/534353
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
TBR=dpranke
Bug: 570091
Change-Id: I1b8cc8156c83c72b2fc599d90059bc7f2674ca17
Reviewed-on: https://chromium-review.googlesource.com/532995
Reviewed-by: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Commit-Queue: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Using goma requires the developer to remember which build directories
use goma and which don't so that they can pass an appropriate -j number.
Getting this wrong makes builds slower, either by under utilizing
resources or by causing a self-inflicted DOS attack. Usage:
autoninja -C out/debug
autoninja looks at the settings for the specified build directory and
then selects either -j num_cores*20 or no -j flag based on the
use_goma setting.
You can set the NINJA_CORE_MULTIPLIER variable to change from the
default 20* multiplier. You can also use NINJA_CORE_ADDITION if you
want non-goma builds to specify -j with an offset to the number of
cores, such as this Linux command:
NINJA_CORE_ADDITION=-2 autoninja -C out/release base
This will tell autoninja to pass -j to ninja with num_cores-2 as the
parameter.
On Windows you can have a ninja.bat file (ahead of ninja on the path)
such that autoninja will automatically be used. It should contain this:
@call autoninja.bat %*
Change-Id: I4003e3fc323d1cbab612999c945b5a8dc5bc6655
Reviewed-on: https://chromium-review.googlesource.com/517662
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Fumitoshi Ukai <ukai@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
This will also be useful for other values (deps_os, hooks_os)
we may want to store and keep constant.
Freeze code copied from luci/recipes-py @ 944125e6d1e8c831d09517bde658a38d8f81db37
Bug: 570091
Change-Id: I3365cf2b267c478316870bbb3fd41e9955aa4ddf
Reviewed-on: https://chromium-review.googlesource.com/531166
Commit-Queue: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
"remote_run" builds explicitly supply a cleanup directory in recipe
properties, so it isn't necessary to supply it here.
BUG=chromium:725631
TEST=None
TBR=iannucci@chromium.org
Change-Id: I6eaaeea14bd699181d7ceeff6b3baac2d1cd9861
Reviewed-on: https://chromium-review.googlesource.com/528630
Reviewed-by: Daniel Jacques <dnj@chromium.org>
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Update the "vpython" CIPD version to pick up schema and runtime
performance changes.
BUG=None
TEST=None
R=iannucci@chromium.org
Change-Id: If0e3c393abb16b8918b5fa16593a8788ef8947ec
Reviewed-on: https://chromium-review.googlesource.com/527608
Reviewed-by: Ryan Tseng <hinoka@chromium.org>
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Currently, "bot_update" relies on a BuildBot cleanup mechanism and, to a
lesser extent, the standard BuildBot directory layout. Both of these are
problematic when projecting it into other circumstances, notably
"remote_run" and LUCI.
Have "bot_update" handle its own cleanup. It will now choose a cleanup
directory within the hierarchy of its checkout, and explicitly purge it
prior to execution if it exists. This enforces its expected behavior in
all circumstances and removes its expectations of the greater checkout
layout.
Export "cleanup_dir" via "infra_paths" to point to "build.dead" when
running on BuildBot builds. Otherwise, it is a default directory which,
on Kitchen, is ephemeral by design.
BUG=chromium:725631
TEST=expectations
Change-Id: I664434c542a25aaa7ff3eac216208a2425730fde
Reviewed-on: https://chromium-review.googlesource.com/528057
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Reviewed-by: Ryan Tseng <hinoka@chromium.org>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).
Please review the expectation changes, and LGTM+CQ.
More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug.
recipe_engine:
https://crrev.com/154ef7e5d8f964ef30b1250dd33751582705f6f2 [path] Add concept of a "cleanup" directory. (dnj@chromium.org)
R=dnj@chromium.org, martiniss@chromium.org
Recipe-Tryjob-Bypass-Reason: Autoroller
Bugdroid-Send-Email: False
Change-Id: I31787615cfaa6f33deae6c1c0c3d7b748c222d05
Reviewed-on: https://chromium-review.googlesource.com/527503
Commit-Queue: Recipe Roller <recipe-roller@chromium.org>
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Reviewed-by: Daniel Jacques <dnj@chromium.org>
This picks up about 2 years worth of changes.
Bug:723733
TEST=Ran gclient sync on src.git checkout, worked.
Change-Id: I7021ac62be560bb3ba7b523f0758d56bceeef12a
Reviewed-on: https://chromium-review.googlesource.com/527262
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Ryan Tseng <hinoka@chromium.org>
This CL changes the way that "git cl patch" behaves for Gerrit changes.
Previously, git-cl-patch behaved just like it did for Rietveld:
make sure you're on a branch, download the diff, apply it on top
of your branch. However, this causes problems with Gerrit. Namely,
when you upload a change to Gerrit, git-cl has to make sure that all
parents of your local change have previously been uploaded as well,
either as other changes or as commits already landed on the target
branch. But the method for "applying a patch" from Gerrit was to
cherry-pick it, and that changes the commit hash. So the resulting
commit would *not* have been uploaded to Gerrit. Thus, the
following routine didn't work with Gerrit:
$ git checkout -t origin/master -b your-work
$ git cl patch 123456
$ git checkout -tb my-work
$ #hack and commit
$ git cl upload
This would fail during the upload with a message saying that the
contents of 'your-work' hadn't been uploaded.
This CL fixes the situation by replacing the cherry-pick with
a hard reset. This means that the contents of the 'your-work'
branch will be *exactly* what was downloaded from Gerrit. Uploads
based on top of that commit will work just fine.
Finally, in a concession to some people who want 'git cl patch'
to actually apply a patch instead of performing a hard reset, if
the current branch contains local work, then rather than leaving
that work behind with a hard reset, we fall back to the old
cherry-pick behavior with a confirmation dialog and warning that
uploading will be hard.
Bug: 723787
Change-Id: I3ad164f6d3078bff00139d446bb8ce97738a1344
Reviewed-on: https://chromium-review.googlesource.com/527345
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
The logic for handling --title, --message, and the
commit message of the most recent commit was accidentally
doing this differently from how Rietveld had done them.
Bug: 728391
Change-Id: I70a46ccb470d790103f5d6bb745902595be28eee
Reviewed-on: https://chromium-review.googlesource.com/527339
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
This prevents TBR (self code-review) permissions from blocking
the CL from being uploaded at all. Instead, it will fully
upload, and then show a better error message after upload is
complete.
Bug: 729967
Change-Id: I55e3e98e200143076afcaab858064d9f5c62f8ef
Reviewed-on: https://chromium-review.googlesource.com/527325
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
This causes review links to be shown using crrev.com/c/ or crrev.com/i/,
which are the ones recommended at https://polygerrit.appspot.com/.
This gerrit server is no longer used only by CrOS.
Change-Id: Ie6b856390ec465f9d35a5035547f7b779392b24c
Reviewed-on: https://chromium-review.googlesource.com/526612
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
This brings the gerrit version of "git cl comments" into line
with the Rietveld implementation by including file- and line-level
comments as well as top-level review comments. It requires an
extra API call to do so, so this may result in some slow-down, but
the result is worth it.
It formats the comments to match the formatting used in the
PolyGerrit UI, with the addition of visible URLs linking to
the comment since we can't hyperlink text in the terminal.
This CL also causes it to ignore messages and comments with
the 'autogenerated' tag, which are generally less interesting
and clutter the output.
Bug: 726514
Change-Id: I1fd939d90259b43886ddc209c0e727eab36cc9c9
Reviewed-on: https://chromium-review.googlesource.com/520722
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
gclient-new-workdir.py should work on systems not supporting reflink now.
Bug: 728903, 721585
Change-Id: I1385c4281bbf61d4ccae64c3595a39972fbe9d9e
Reviewed-on: https://chromium-review.googlesource.com/522232
Commit-Queue: Wei-Yin Chen (陳威尹) <wychen@chromium.org>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Using --no-squash resulted in an exception being thrown, because issue
number is not set in that case.
Change-Id: Iaf0d7eb05851eba0d5231640c077b845bca486ee
Reviewed-on: https://chromium-review.googlesource.com/505509
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Bruce Dawson
Paweł Hajdan, Jr
recipe-roller
Robert Iannucci
Aaron Gable
Andrii Shyshkalov
Dan Jacques
Ryan Tseng
Jeremy Roman
Wei-Yin Chen (陳威尹)
Wiktor Garbacz