Hypothesis: Sometimes bot update fails because windows fails to delete
a lockfile associated with a git process.
Test: If this happens, let's delete that lockfile and try again.
BUG=651602
Review-Url: https://codereview.chromium.org/2382653005
Reason for revert:
Didn't help.
Original issue's description:
> gclient: kill git fetch operation that hangs.
>
> This provides env variable GCLIENT_KILL_GIT_FETCH_AFTER
> that kills git fetch if it produces no output for that
> many seconds.
>
> Note that this is not final patch, but an experiment.
> See http://crbug.com/635641#c24 for the deployment plan.
>
> BUG=635641
> R=hinoka@chromium.org
>
> Committed: f8757b7e02
TBR=hinoka@chromium.org,hinoka@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=635641
Review-Url: https://codereview.chromium.org/2410853002
Reason for revert:
didn't work.
Original issue's description:
> bot_update/gclient: kill git fetch after timeout regardless of output.
>
> Also spits out whatever output was produced by git fetch for debugging.
>
> BUG=635641
> R=machenbach@chromium.org,hinoka@chromium.org
>
> Committed: db8b839320
TBR=hinoka@chromium.org,machenbach@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=635641
Review-Url: https://codereview.chromium.org/2410053002
The flow looks like this:
$ git cl status
Branches associated with reviews:
gerrit-4483 : https://chromium-review.googlesource.com/381231 (waiting)
$ git cl try-results
Warning: Codereview server has newer patchsets (2) than most recent
upload from local checkout (None). Did a previous upload fail?
By default, git cl try uses latest patchset from codereview,
continuing using such patchset 2.
Warning: Some results might be missing because You are not logged in.
Please login first by running:
depot-tools-auth login chromium-review.googlesource.com
Started:
Infra Linux Precise 32 Tester https://luci-milo.appspot.com/swarming/...
Infra Linux Trusty 64 Tester https://luci-milo.appspot.com/swarming/...
Total: 2 try jobs
$ depot-tools-auth login chromium-review.googlesource.com
<<<auth in my browser>>>
Logged in to chromium-review.googlesource.com as <some@email.com>
To login with a different email run:
depot-tools-auth login chromium-review.googlesource.com
To logout and purge the authentication token run:
depot-tools-auth logout chromium-review.googlesource.com
$ git config branch.gerrit-4483.gerritpatchset 2
$ git cl try-results
Started:
Infra Linux Precise 32 Tester https://luci-milo.appspot.com/swarming/...
Infra Linux Trusty 64 Tester https://luci-milo.appspot.com/swarming/...
Infra Mac Tester https://luci-milo.appspot.com/swarming/...
Total: 3 try jobs
R=sergiyb@chromium.org,emso@chromium.org
BUG=599931
TEST=new unittests + end-to-end local.
Review-Url: https://codereview.chromium.org/2392463009
No stacktrace is printed, instead just a user-friendly string is shown.
Add test + some tests refactoring.
This CL also improve missing Gerrit issue exception elsewhere by raising
user-friendly exception.
BUG=654360
R=sergiyb@chromium.org
TEST=manual
Review-Url: https://codereview.chromium.org/2403793002
Reason for revert:
Actually, it doesn't break uploads, add cc-ed emails post-upload fails with exception and confuses users, and I couldn't find workaround.
Original issue's description:
> Add CC_LIST and --cc to Gerrit issues via API to be similar to CCs in Rietveld
>
> BUG=chromium:649660
>
> Committed: 3574740929TBR=rmistry@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:649660
Review-Url: https://codereview.chromium.org/2375393002
Reason for revert:
Pointing to the wrong file :(
Original issue's description:
> bot_update: add --auth-refresh-token-json passthrough for apply_issue
>
> BUG=642150
>
> Committed: e465667e78
TBR=vadimsh@chromium.org,martiniss@chromium.org,tandrii@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=642150
Review-Url: https://codereview.chromium.org/2350363003
Currently, if a DEPS file sets use_relative_paths, but *also* sets
recursedeps, then the recursed-upon DEPS files still get checked
out relative to the .gclient root. This change makes it so that
recursed-upon DEPS files check their dependencies out relative to
where their parent wants them to be, if that parent sets
use_relative_paths=True.
R=maruel@chromium.org
Review-Url: https://codereview.chromium.org/2324513003
This makes it easier to reason about tests which care about
both the url being fetched and the directory to which it is
being fetched, like those concerning relative paths and
recursion.
R=maruel@chromium.org
Review-Url: https://codereview.chromium.org/2316963004
For use in scripts that check try job results, this is
currently practically the same as making requests to
https://codereview.chromium.org/api/<cl-number>/<patchset-number>.
However, I think that this might be more future-proof, since
it fetches try job information from Buildbucket, and I expect
to still work after migration from Rietveld to Gerrit.
BUG=640354
Review-Url: https://codereview.chromium.org/2274743003
Also spits out whatever output was produced by git fetch for debugging.
BUG=635641
R=machenbach@chromium.org,hinoka@chromium.org
Review-Url: https://codereview.chromium.org/2293013002
This CL adds a couple flags to "git cl archive".
dry-run: Lists the cleanup tasks, but exits before any changes are
made to Git.
notags: Deletes branches only; does not create archival tags.
R=tandrii@chromium.org,groby@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2276663002
Previously there was a soup with add-hoc formatting with
current branch name, which wasn't always set (see bug 611020).
This CL makes sure all such operations now:
* properly use types --int and --bool
* go through the *only* appropriate get/set/unset function.
Furthermore, tests were a mess wrt to raising exceptions when
git processes terminated with an exception. This CL cleaned up,
though I didn't go through all expectations, so some returns of
empty stdout instead of raising CalledProcess error are likely
remaining.
Disclaimer: this CL is not necessarily fixing the referenced bug
below, but it should at least provide better stacktrace when
the bug manifestst itself.
BUG=611020
R=agable@chromium.org
Review-Url: https://codereview.chromium.org/2259043002
This allows users to specify additional local presubmit tests that
do not need to exist as locally maintained changes to PRESUBMIT.py
files.
BUG=
Review-Url: https://codereview.chromium.org/2232203002
Since different projects can have different configurations for what
the maximum value of the "Code-Review" label is in Gerrit, this teaches
presubmit_support to inspect the maximum configured value and see who
has granted it (the same behavior as the Submit button in Gerrit itself).
R=andybons@chromium.org, martiniss@chromium.org, tandrii@chromium.org
BUG=630738
Review-Url: https://codereview.chromium.org/2178673002
Previously if you deleted a file that you had per-file owners on, it would fail
the owners check. This fixes that.
Originally, owners.Database used glob to enumerate the directory and added all
the matching files in the directory to some dicts holding the owners
information. If a CL deleted a file, it'd no longer be on the filesystem, so it
wouldn't be in these dicts. There'd be no per-file owners information for it.
With this patch, the Database no longer enumerates individual files. It instead
keeps track of the glob patterns and checks the CL's files against the patterns
at lookup time.
BUG=622381
TEST=tests/owners_unittest.py && tests/owners_finder_test.py # Unit test included.
Review-Url: https://codereview.chromium.org/2148153002
If an OWNERS file used the file: directive with a relative file
path, but was using a root other than '/' (e.g.
'/path/to/my/real/root'), then the include resolver would incorrectly
leave a leading '/' on the include path. When os_path.join was then
called, the leading '/' meant the path was treated as an absolute path
and the join did not behave as expected.
Review-Url: https://codereview.chromium.org/2148683003
If bots are specified manually on command line OR in PRESUBMIT.py,
then old behavior remains, namely triggering just those bots.
Otherwise, git cl try will now trigger CQ Dry Run. This is a good
default and also resolves several bugs:
* https://crbug.com/581150 where git cl try used to load cq.cfg
from infra/config, but that's not always correct for all projects.
* https://crbug.com/625697 where even if cq.cfg is in default location.
it might be outdated.
* https://crbug.com/585237 where git cl try would ignore special
in CL description CQ_INCLUDE_TRYBOTS, which is processed by CQ,
but not git cl try.
BUG=625697,585237,581150
R=sergiyb@chromium.org,emso@chromium.org
Review-Url: https://codereview.chromium.org/2147563003
katthomas
lpique
agable
tandrii
rmistry
stip
hinoka
iannucci
dsansome
qyearsley
scottmg
kmarshall
phajdan.jr
tobiasjs
wychen
smut
dtu
mbjorge