Skip to content

C
Chromium_Depot_tools
Switch branch/tag
  1. 27 Feb, 2021 1 commit
    • Bruce Dawson's avatar
      Reland "Check whether goma is running when it is enabled" · e952faee
      Bruce Dawson authored 
      This reverts commit 428143ee.

Reason for revert: Fixing the issues revealed by the original change by
avoiding python3 and by checking for the existence of gomacc[.exe]
before running it.

This also relands 2241db8a - "Avoid
capture_output to support Python 3.6", to simplify relanding and any
possible reverts.

Original change's description:
> Revert "Check whether goma is running when it is enabled"
>
> This reverts commit b7ddc5a0.
>
> Reason for revert:
> This broke the builder where depot_tools is not in PATH.
> https://logs.chromium.org/logs/infra-internal/buildbucket/cr-buildbucket.appspot.com/8858077852309878080/+/u/build/stdout
>
> Original change's description:
> > Check whether goma is running when it is enabled
> >
> > One of the mistakes one can make when running ninja is having goma
> > enabled (use_goma=true in args.gn) but not having goma running. This can
> > lead to ~1,000 failed compile steps, which is messy.
> >
> > This change teaches autoninja.py to check whether goma is running. If
> > not then it tells autoninja to just print a warning message. The
> > check costs roughly 30 ms which seems reasonable.
> >
> > In fact, because this change also switches away from vpython (necessary
> > to use python3 to use subprocess.run) it actually runs about 600 ms
> > _faster_ than before this change.
> >
> > If build acceleration is requested through use_rbe then no checking for
> > whether the service is running is done. That could be added in the
> > future.
> >
> > autoninja.py could auto-start goma but that is error prone and has
> > limited additional value.
> >
> > This was tested on Linux, OSX, and Windows.
> >
> > Bug: 868590, b/174673874
> > Change-Id: Ie773e574878471e5136b9b82d52f86af3d848318
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2627014
> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> > Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@google.com>
>
> TBR=yyanagisawa@google.com,dpranke@google.com,brucedawson@chromium.org,sanfin@chromium.org,infra-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I57a6c73ea853259f3d1ec7ad0ce51e495acc96db
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 868590
> Bug: b/174673874
> Bug: 1167064
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2632018
> Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@google.com>
> Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@google.com>

TBR=yyanagisawa@google.com,dpranke@google.com,brucedawson@chromium.org,sanfin@chromium.org,infra-scoped@luci-project-accounts.iam.gserviceaccount.com

# Not skipping CQ checks because this is a reland.

Bug: 868590
Bug: b/174673874
Bug: 1167064
Change-Id: I8aa6830259bc18f8e7926cd0bf5c62e671c74a2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2634201Reviewed-by: 's avatarBruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarDirk Pranke <dpranke@google.com>
Reviewed-by: 's avatarFumitoshi Ukai <ukai@google.com>
Reviewed-by: 's avatarYoshisato Yanagisawa <yyanagisawa@google.com>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
      e952faee
  3. 26 Feb, 2021 2 commits
  5. 25 Feb, 2021 2 commits
  7. 24 Feb, 2021 5 commits
  9. 23 Feb, 2021 4 commits
  11. 22 Feb, 2021 1 commit
  13. 19 Feb, 2021 2 commits
  15. 18 Feb, 2021 2 commits
    • Bruce Dawson's avatar
      Robustly set issue number · f362f6f9
      Bruce Dawson authored 
      When using "git cl patch -b branch_name issue_number" to resolve merge
conflicts in an uploaded CL the cherry-pick stage will probably fail due
to the expected merge conflicts. If you resolve the conflict and then
upload the now-merged CL you will actually create a new CL. This happens
because the SetIssue step is skipped when the cherry-pick fails.

This change sets the issue whenever a new branch is created. This is
safe (the new branch is not being used for anything else) and will
improve the situation in many cases.

crrev.com/c/2636593 is an example of a CL that was accidentally uploaded
as new when it was just supposed to be a resolving of merge conflicts on
an existing CL.

This change was manually tested with crrev.com/c/2107132.

Change-Id: Icb5b8e38feb6f0fa4a007d3924c4d69d2ee4937c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2638979
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarGavin Mak <gavinmak@google.com>
      f362f6f9
    • Antonio Sartori's avatar
      Make git map-branches faster · e0dff208
      Antonio Sartori authored 
      This change makes git map-branches a little bit faster by avoiding
fetching the revision list of each branch if git map-branches will not
show the tracking info anyway.

Change-Id: I47458871f904004f910aadd7d774bea5193c979e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2695393Reviewed-by: 's avatarAnthony Polito <apolito@google.com>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      e0dff208
  17. 17 Feb, 2021 4 commits
  19. 16 Feb, 2021 3 commits
  21. 12 Feb, 2021 3 commits
  23. 11 Feb, 2021 2 commits
  25. 10 Feb, 2021 2 commits
  27. 09 Feb, 2021 5 commits
  29. 08 Feb, 2021 2 commits