Use 'realpath' instead of 'abspath' for self-discovery. This fixes an
issue where 'gsutil' cannot find its dependencies when it is referenced
through a symbolic link.
Specifically, the symlink was: /b/scripts => /b/build/scripts
'gsutil' was called as:
/b/scripts/slave/../../../depot_tools/third_party/gsutil/gsutil
Because '/b/scripts/slave' resolves to '/b/build/scripts/slave', the three
parent directory operators actually resolve to '/b', but 'os.path.abspath'
blindly resolves them to '/'.
BUG=chromium:474442
TEST=live
- Signed onto failing bot, made this change, 'gsutil' works.
R=hinoka@chromium.org
Review URL: https://codereview.chromium.org/1060353002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294712 0039d316-1c4b-4281-b951-d872f2087c98
This is already fixed upstream in gsutil.
BUG=None.
TEST=None.
Review URL: https://codereview.chromium.org/341833005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@280386 0039d316-1c4b-4281-b951-d872f2087c98
The "What is your project ID" has confused about every user of gsutil that I've
talked to, and isn't even useful in the context of download_from_google_storage
because its only good for "mb" on a bucket and "ls" without specifying a bucket,
neither of which this version of gsutil should ever do.
This CL:
* Removes the prompt for project ID
* Removes the 2 second delay which was meant for autolaunching a browser
* We don't want this behavior anyways because most of our devs have multiple
browser profiles open and they need to paste the URL into the correct profile.
* Removes support to autolaunch a broswer.
* Removes a lot of the extra messages. The prompt now looks like:
===
$ download_from_google_storage -g
Please navigate your browser to the following URL:
https://accounts.google.com/o/oauth2/auth?.....
Enter the authorization code: <code>
Boto config file "/usr/local/google/home/hinoka/.boto.depot_tools" created.
$
===
BUG=351015
Review URL: https://codereview.chromium.org/222973002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@267973 0039d316-1c4b-4281-b951-d872f2087c98
The Telemetry workflow happily uses this gsutil to download artifacts, but they would also like to use the same workflow to upload artifacts.
I don't see a big harm in enabling read_write access for prodaccess based gsutil since its already more restrictive than the normal gsutil auth flow. I could also be convinced to make this full_control, but that need has not arisen yet.
BUG= 341665
Review URL: https://codereview.chromium.org/148203012
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@259761 0039d316-1c4b-4281-b951-d872f2087c98
It looked like the bypass_prodaccess flag wasn't passed in all the way to
where it needed to be, causing it to be set to True by default at some point,
which caused the prodaccess path to never happen. This change takes the flag
and brings it all of the way.
BUG=337972
Review URL: https://codereview.chromium.org/147443002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@247049 0039d316-1c4b-4281-b951-d872f2087c98
By default, if loasd is not running, loas_check retries twice, waiting 5 seconds between retries. This is in case loasd is restarting due to reinstallation. Unfortunately, if the user has never run prodaccess, this check takes an extra 10 seconds. So, just disable the retries.
BUG=
Review URL: https://codereview.chromium.org/137853024
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@245399 0039d316-1c4b-4281-b951-d872f2087c98
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
boto config does the right thing by using the http_proxy env var to set the proxy,
and gsutil removes that var which isn't the behavior we want.
This should allow gsutil to respect the http_proxy env var.
BUG=318478
Review URL: https://codereview.chromium.org/68763013
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@235818 0039d316-1c4b-4281-b951-d872f2087c98
dnj@chromium.org
dtu@chromium.org
hinoka@chromium.org
pgervais@chromium.org
hinoka@google.com