1. 16 Dec, 2013 1 commit
  2. 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
  3. 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
  4. 10 Dec, 2013 2 commits
  5. 09 Dec, 2013 2 commits
  6. 06 Dec, 2013 1 commit
  7. 05 Dec, 2013 2 commits
  8. 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
  9. 03 Dec, 2013 2 commits
  10. 02 Dec, 2013 1 commit
  11. 28 Nov, 2013 1 commit
  12. 27 Nov, 2013 1 commit
  13. 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
  14. 25 Nov, 2013 3 commits
  15. 21 Nov, 2013 1 commit
  16. 20 Nov, 2013 1 commit
  17. 19 Nov, 2013 3 commits
  18. 18 Nov, 2013 1 commit
  19. 17 Nov, 2013 1 commit
  20. 15 Nov, 2013 2 commits
  21. 14 Nov, 2013 3 commits
  22. 13 Nov, 2013 1 commit
  23. 11 Nov, 2013 1 commit
  24. 08 Nov, 2013 1 commit
  25. 07 Nov, 2013 2 commits