Skip to content

C
Chromium_Depot_tools
Switch branch/tag
  1. 07 Jan, 2014 2 commits
  3. 06 Jan, 2014 1 commit
  5. 03 Jan, 2014 2 commits
  7. 21 Dec, 2013 1 commit
  9. 19 Dec, 2013 1 commit
  11. 18 Dec, 2013 3 commits
  13. 16 Dec, 2013 3 commits
  15. 13 Dec, 2013 1 commit
    • digit@chromium.org's avatar
      fetch.py: Add '--nohooks' option. · 3596d585
      digit@chromium.org authored 
      'fetch chromium' will fail if the build dependencies are not already installed
on the host machine, because it runs 'gclient sync' which, by default, will run
hooks that will try to run build/gyp_chromium (which will then fail).

This introduces a --nohooks option that solve the problem by allowing the
user to do the following:

  1) fetch --nohooks <recipe>
  2) src/build/install-build-deps.sh
  3) fetch <recipe>

BUG=325795
TEST=Run 'fetch --nohooks chromium' in a temporary 'clean' chroot directory.
R=maruel@chromium.org,jochen@chromium.org,scottmg@chromium.org,agable@chromium.org

Review URL: https://codereview.chromium.org/106403003

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@240680 0039d316-1c4b-4281-b951-d872f2087c98
      3596d585
  17. 12 Dec, 2013 3 commits
    • bratell@opera.com's avatar
      Avoid windows presubmit hang in gclient tests. · 0ee42a68
      bratell@opera.com authored 
      If os.kill(os.getpid(), signal.CTRL_C_EVENT) doesn't do what the
test author hopes it will do, the test will hang until it has calculated
a million out-of-thread/process results. That is approximately an
infinite hang.

BUG=

Review URL: https://codereview.chromium.org/110883004

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@240319 0039d316-1c4b-4281-b951-d872f2087c98
      0ee42a68
    • bratell@opera.com's avatar
      Don't run presubmit checks on python276_bin. · 154c36c3
      bratell@opera.com authored 
      Actually, don't run presubmit checks on anything starting with
python and ending with _bin.

BUG=326975

Review URL: https://codereview.chromium.org/111643002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@240316 0039d316-1c4b-4281-b951-d872f2087c98
      154c36c3
    • hinoka@chromium.org's avatar
      Adds SSO auth to gsutil · c6a2ee69
      hinoka@chromium.org authored 
      Code path:
1. plugins.sso_auth is imported, which adds the AuthHandler class to the global state.
2. HasConfiguredCredentials() in gslib/utils.py is called by gsutil, and will return true if "prodaccess" exists on the system, which tells the system that we don't want a no-op auth handler.
3. When a command is called, all the auth handlers are cycled through and sso_auth.SSOAuth is called, which calls a stubby command to emit a gaiamint'ed oauth2 access token, which is then used as the Authorization Header

if --bypass_prodaccess is passed in, then:
1. HasConfiguredCredentials() will bypass the check for prodaccess, as if it didn't exist.
2. plugins.sso_auth does not get imported.
Which will essentially cause gsutil to behave as if this patch never existed.

So the expected behavior is:
=.boto file does not exist, prodaccess exists, but unauthenticated=
Failure: No handler was ready to authenticate. 3 handlers were checked. ['OAuth2Auth', 'HmacAuthV1Handler', 'SSOAuth'] Check your credentials.

=.boto file exists, prodaccess exists, but unauthenticated=
sso_auth will raise NotReadyToAuthenticate, and the .boto file will be used instead

=.boto file exists, prodaccess exists, authenticated=
sso_auth will be run _after_ the default gsutil authenticator, which causes the sso_auth to be used over whatever the default authentication is.

bypass_prodaccess is passed in by default to upload_to_google_storage because we expect people who use upload_to_google_storage to not need prodaccess and have their own boto file already.  Also the sso_auth plugin will only request a readonlyi token, which will not work for uploading.

BUG=258152

Review URL: https://codereview.chromium.org/86123002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@240266 0039d316-1c4b-4281-b951-d872f2087c98
      c6a2ee69
  19. 10 Dec, 2013 2 commits
  21. 09 Dec, 2013 2 commits
  23. 06 Dec, 2013 1 commit
  25. 05 Dec, 2013 2 commits
  27. 04 Dec, 2013 1 commit
    • cranger@google.com's avatar
      Use the latest gerrit 2.8 RC · 80612bab
      cranger@google.com authored 
      googlesource.com runs close to master and the latest gerrit RC is
closest to that. Furthermore, this allows the tests to use the latest
REST api endpoints (including create account).

Fix the sorting of gerrit versions to extend the major revsion numbers
before the RC numbers. This makes 2.7-rc4 comparable to 2.7.1.

The gerrit init command now requires download-commands plugin to be
installed in order for the revisions fetch field to be populated (i.e
to show the download schemes).

NOTRY=true

Review URL: https://codereview.chromium.org/69373002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@238631 0039d316-1c4b-4281-b951-d872f2087c98
      80612bab
  29. 03 Dec, 2013 2 commits
  31. 02 Dec, 2013 1 commit
  33. 28 Nov, 2013 1 commit
  35. 27 Nov, 2013 1 commit
  37. 26 Nov, 2013 2 commits
    • maruel@chromium.org's avatar
      Revert r235548 "Add a Yo Dawg to wake up folks." · 103f6d38
      maruel@chromium.org authored 
      Internal teams are relying on git-try as the sole mean to run try jobs so revert
this.

Hopefully most target users (chromium folks) got the message at least once.

R=cmp@chromium.org
BUG=

Review URL: https://codereview.chromium.org/88743003

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@237361 0039d316-1c4b-4281-b951-d872f2087c98
      103f6d38
    • maruel@chromium.org's avatar
      Fix unpinned version to track upstream. · 1a60dca7
      maruel@chromium.org authored 
      This is a serious bug, if a version is unpinned, it would become stuck at
whatever a local branch 'master' may point to. This is extremely bad when a
pinned dependency is unpinned on purpose, for example on a canary master. We
reproduced this problem on the chromium.swarm master by setting a custom_vars
swarming_revision to '', which then stopped syncing at the expected
origin/master commit but instead got stuck to what happened to be a local master
branch.

This happens on git dependencies if the main solution is using svn. This doesn't
happen on git checkouts using .DEPS.git due to bug 323233.

The issue looks like:
________ running 'git reset --hard HEAD' in '/path/src/tools/swarming_client'
HEAD is now at 4727bd5 Some commit
Checked out revision d908a546e28d1e9f85f5690cf6c3a080f06ba711

Note that HEAD and what is checked out do not match.

Also reduce the hardcoding of 'origin' by creating a variable named 'remote'.

R=petermayo@chromium.org
BUG=322961

Review URL: https://codereview.chromium.org/85473007

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@237332 0039d316-1c4b-4281-b951-d872f2087c98
      1a60dca7
  39. 25 Nov, 2013 3 commits
  41. 21 Nov, 2013 1 commit
  43. 20 Nov, 2013 1 commit
  45. 19 Nov, 2013 3 commits