- 03 Apr, 2015 1 commit
-
-
pasko@chromium.org authored
Also fix some latent bugs in the unit tests. (cherry-picked by pasko@ from https://codereview.chromium.org/1048103002/) BUG=467005 Review URL: https://codereview.chromium.org/1059723003 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294674 0039d316-1c4b-4281-b951-d872f2087c98
-
- 26 Feb, 2015 1 commit
-
-
sbc@chromium.org authored
Handle KeyboardInterrupt gracefully rather the printing a backtrace. Most users of these tools don't expect a backtrace when then hit Ctrl-C. Also, fix a few other inconsistencies found in the python startup code of these different scripts: - always call main function 'main' (rather than 'Main') - always return 0 from main function - if main takes args never include argv[0] Review URL: https://codereview.chromium.org/955993006 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294250 0039d316-1c4b-4281-b951-d872f2087c98
-
- 17 Feb, 2015 1 commit
-
-
primiano@chromium.org authored
Currently check_bucket_permissions() in download_from_google_storage.py performs a gsutil ls gs://bucket to determine whether the user has access to the bucket or not. This can be an EXTREMELY expensive operation (~minutes) if the bucket in question has a lot of objects in the root (real case: chrome-telemetry). It is worth noting that check_bucket_permissions() is not called just for uploads but also for downloads, hence this is slowing down all invocations of gclient sync on users and bots machine. Removing the check_bucket_permissions() and let gsutil fail with an Unauthorized error message if ACLs are not met. BUG=458059 Review URL: https://codereview.chromium.org/923473002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294083 0039d316-1c4b-4281-b951-d872f2087c98
-
- 17 Dec, 2014 1 commit
-
-
hinoka@chromium.org authored
This pins gsutil to a vanilla 4.7 instead of the weird custom 3.4 we have in depot_tools BUG= R=pgervais@chromium.org Review URL: https://codereview.chromium.org/797663003 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293413 0039d316-1c4b-4281-b951-d872f2087c98
-
- 05 Dec, 2014 1 commit
-
-
ojan@chromium.org authored
r293250 broke it. I didn't realize that check_bucket_permissions was shared code. It now only returns a single value. TBR=vadimsh@chromium.org Review URL: https://codereview.chromium.org/782643002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293256 0039d316-1c4b-4281-b951-d872f2087c98
-
- 12 Dec, 2013 1 commit
-
-
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
-
- 28 Oct, 2013 1 commit
-
-
brettw@chromium.org authored
Adds a command line flag --platform to control which platforms the given download occurs on. Automatically marks downloads executable on non-Windows if the header x-goog-meta-executable is set. Automatically set this flag on upload when the executable bit is set. BUG=233100 Review URL: https://codereview.chromium.org/42273002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@231387 0039d316-1c4b-4281-b951-d872f2087c98
-
- 28 Jun, 2013 1 commit
-
-
ukai@chromium.org authored
R=hinoka@chromium.org,maruel@chromium.org BUG=254817 Review URL: https://chromiumcodereview.appspot.com/17992005 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@209037 0039d316-1c4b-4281-b951-d872f2087c98
-
- 13 Mar, 2013 1 commit
-
-
hinoka@google.com authored
continuation of: https://codereview.chromium.org/11664024 Moved it from chrome/trunk/src/build to depot_tools/ BUG=153360 TEST=two unittests included in tests/ For end-to-end testing, check out a large directory. Run find . -name .svn -prune -o -size +1000k -type f -print0 | upload_to_google_storage.py -b chrome-artifacts -0 - (replacing chrome-artifacts with an upload-able bucket) to test upload run "find . -name .svn -prune -o -size +1000k -type f -print0 | xargs -0 rm" to remove the files uploaded. Check that the large binary files have been removed run "download_from_google_storage.py -r -d -b chrome-artifacts ." to download the files again. Review URL: https://chromiumcodereview.appspot.com/12042069 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@187951 0039d316-1c4b-4281-b951-d872f2087c98
-