A very common pattern for the users of this script is to have binaries in
three different folders, eg:
some/folder/win/bin.exe
some/folder/mac/bin
some/folder/linux/bin
Instead of using --platform to specify three different paths, we can recognize
this usage and pass in --auto_platform, and then --directory some/folder/ as the
target.
When enumerating files, it will match each individual file to see if they have
(win|mac|linux) as a parent folder name, and filter out non-matching platforms.
BUG=
TEST= src/third_party/clang_format/bin$ download_from_google_storage --auto_platform --no_auth -b chromium-clang-fomat -dr .
0> Downloading ./linux/clang-format...
Review URL: https://codereview.chromium.org/126893002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@245643 0039d316-1c4b-4281-b951-d872f2087c98
When download_from_google_storage --config is run, it should be implied that
the user just wants to download, not upload. This change passes the '-r' flag
into gsutil config, which requests a read-only scoped token rather than write
token. This is saved in ~/.boto.depot_tools so that it doesn't conflict
with a ~/.boto file crated later that may have write permissions.
BUG=
Review URL: https://codereview.chromium.org/135153002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@244276 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
This should make Cygwin work to match "win32".
Review URL: https://codereview.chromium.org/108743002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@239244 0039d316-1c4b-4281-b951-d872f2087c98
This normalizes sys.platform so people running cygwin are treated like Windows.
Review URL: https://codereview.chromium.org/104763003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@238999 0039d316-1c4b-4281-b951-d872f2087c98
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
We appear to be getting 403's when encountering errors other than mismatched
credentials. The error message was originally hidden to avoid clutter, but it
has become obvious that there are other transient errors hidden behind a 403.
This change prints the original gsutil error message regardless of whether or not
we enconter a 403 or 404.
BUG=
Review URL: https://chromiumcodereview.appspot.com/23484061
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@224195 0039d316-1c4b-4281-b951-d872f2087c98
Able to pull internal tools, but distinct from the source that
those tools may eventually build.
TBR=cmp@chromium.org
BUG=252226
TEST=local buildslave
Review URL: https://chromiumcodereview.appspot.com/17351008
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@209166 0039d316-1c4b-4281-b951-d872f2087c98
In order to support both developer workflow and not breaking bots, if the script
fails on a 403 in a bucket, it'll print a message asking developers to run
"download_from_google_storage --config" in order to create a new boto file.
This is not done automatically because it would break bots (Imagine hitting a 403,
and then gsutil wiping the .boto file, waiting for input, then dying).
BUG=231699,176331
Review URL: https://chromiumcodereview.appspot.com/17590010
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@208806 0039d316-1c4b-4281-b951-d872f2087c98
It appears to be parsed and ignored, seems like a bug to me.
BUG=None
TEST=local/manual.
Review URL: https://chromiumcodereview.appspot.com/17265012
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@207404 0039d316-1c4b-4281-b951-d872f2087c98
When a developer runs download_from_google_storage, and they don't have a .boto
file, the tool automatically runs "gsutil config" to create one for them.
Unfortunately, a side consequence is that if a bot runs the script, and it has
a boto file that 403's, then it would run "gsutil config" which moves the .boto
to .boto.bak, and creates an empty .boto file. This should not be the intended
action.
This CL changes so that "gsutil config" is not called, but instead just fails
with a message telling the dev to run that command.
TBR=maruel@chromium.org
Review URL: https://codereview.chromium.org/16072023
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@203824 0039d316-1c4b-4281-b951-d872f2087c98
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
hinoka@google.com
hinoka@chromium.org
brettw@chromium.org
scottmg@chromium.org
petermayo@chromium.org