Apparently several scripts in other repros call this function directly.
Bug: 772741
Change-Id: I486483e44a072af6cf8c75373a2da6ef5469fc2c
TBR=dpranke
Reviewed-on: https://chromium-review.googlesource.com/707937
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
The script prints a bunch of stuff behind `if verbose` checks, but then
"verbose" was turned on by default in
https://bugs.chromium.org/p/chromium/issues/detail?id=504452
I think the wrong lesson was learned from that bug – it sounds like the
problem was that an error message was printed only if verbose was set.
After this change, the script is silent when it does nothing, and prints
something if something happens. (Arguably, it still prints too much in the
case where it successfully downloads something.)
This is part of a few changes to make `gclient runhooks` less noisy.
Bug: 772741,504452
Change-Id: I5823c296abe97611ba4411bab2743673b10dca4b
Reviewed-on: https://chromium-review.googlesource.com/706915
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Ryan Tseng <hinoka@chromium.org>
This picks up about 2 years worth of changes.
Bug:723733
TEST=Ran gclient sync on src.git checkout, worked.
Change-Id: I7021ac62be560bb3ba7b523f0758d56bceeef12a
Reviewed-on: https://chromium-review.googlesource.com/527262
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Ryan Tseng <hinoka@chromium.org>
Without this change, the extracted directory could be missing but
the downloaded file could match the hash, and in turn
download_from_google_storage will not download the file and will
not extract it, and any tools depending on the extracted
directory will fail.
Review URL: https://codereview.chromium.org/1904483002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@300051 0039d316-1c4b-4281-b951-d872f2087c98
I fixed the overlapping argument and fixed up the tests so that the actual sha1 hash is now passed (since the tool actually check now that the downloaded file hash matches)
BUG=
R=hinoka@google.com
Review URL: https://codereview.chromium.org/1285423002 .
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@296346 0039d316-1c4b-4281-b951-d872f2087c98
This does one last check to see if the file downloaded by
download_from_google_storage.py actually matches its sha1
BUG=
Review URL: https://codereview.chromium.org/1252313005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@296155 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
This conflicts with (and duplicates?) the -z option below and has broken one of the chrome android downstream bots.
Safer to revert than trying to fix
Original issue's description:
> Add support for tar.gz archive files to download from download_from_google_storage
>
> Also, add support for directly setting the public read flag on uploaded files.
>
> The support for tar.gz allows the uploaded bundle to be a single tar.gz file instead of a lot of individual files using the directory support already in. The benefit here is that it is much easier to update the dependency. Simply clean out the existing files, copy in the new ones, create a tar.gz file, with the same name as the directory + 'tar.gz'. If the directory name and file name does not match up we will not clean up existing artifacts on download (i.e., there can be left over files after extracting).
>
> I am doing this because I am moving a bunch of the dart dependencies to gcs, and a lot of our dependencies is much easier to manage with this in. If you don't like this, I can simply wrap the download script in another python script and do the logic there, but this may be handy for other people as well.
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=295872
TBR=hinoka@google.com,hinoka@chromium.org,azarchs@chromium.org,ricow@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1209033006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295883 0039d316-1c4b-4281-b951-d872f2087c98
Also, add support for directly setting the public read flag on uploaded files.
The support for tar.gz allows the uploaded bundle to be a single tar.gz file instead of a lot of individual files using the directory support already in. The benefit here is that it is much easier to update the dependency. Simply clean out the existing files, copy in the new ones, create a tar.gz file, with the same name as the directory + 'tar.gz'. If the directory name and file name does not match up we will not clean up existing artifacts on download (i.e., there can be left over files after extracting).
I am doing this because I am moving a bunch of the dart dependencies to gcs, and a lot of our dependencies is much easier to manage with this in. If you don't like this, I can simply wrap the download script in another python script and do the logic there, but this may be handy for other people as well.
Review URL: https://codereview.chromium.org/807463005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295872 0039d316-1c4b-4281-b951-d872f2087c98
This does two noticable things:
* Prints a message when "download_from_google_storage --config" is run to
tell the user to enter "0" for the project ID prompt
* Removes the ".boto.depot_tools" boto file and defaults the boto file to
grant fullcontrol scopes.
Context: We restricted the depot_tools specific scopes to be readonly out of
concern that we would be forcing every developer to hold a set of non-expiring
write access credentials on their workstation. But this distinction has caused
a great deal of pain and anguish with confusing credentials (who would've thought
~/.boto.depot_tools would exist and might be broken?), and not for huge security
gains. Most people don't have write access to buckets, and the ones that do
definitely has a fullcontrol boto file already.
BUG=
Review URL: https://codereview.chromium.org/1182583003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295728 0039d316-1c4b-4281-b951-d872f2087c98
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
This prevents --no_auth from always clearing BOTO_CONFIG, since there
are times when a BOTO is needed for other things than just auth info
(e.g. proxy settings).
BUG=443523
R=hinoka@chromium.org, szager@chromium.org
Review URL: https://codereview.chromium.org/844373002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293652 0039d316-1c4b-4281-b951-d872f2087c98
The new GSUtil (or gs protocol, who knows) strips off the redundent x-goog-meta
string from the metadata key. This CL compensates for that.
Also since we're on 4.7, we can use the faster gsutil stat instead of gsutil ls -L.
BUG=
TEST=ran download_from_google_storage against compiler_proxy.sha, works
NOTREECHECKS=true
NOTRY=true
R=dnj@chromium.org, pgervais@chromium.org
Review URL: https://codereview.chromium.org/809123003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293432 0039d316-1c4b-4281-b951-d872f2087c98
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
--sha1_filename unnecessarily forces the output to have
the same filename and be in the same directory. The code
in main already correctly sets the file name to the
sha1_filename minus the .sha1, so the only change is
to actually use the --output path the same way the
rest of the code does.
R=iannucci@chromium.org
Review URL: https://codereview.chromium.org/752803003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293251 0039d316-1c4b-4281-b951-d872f2087c98
Checking bucket permissions takes ~400ms. We don't
need to do this if --no-auth because we know we
won't get a 403 and the 404 check will be handled
later when we try to actually download the file.
Also, remove the check for a null bucket. This
can't happen since we will throw a parser error
in the main function before we get to this code.
R=iannucci@chromium.org
Review URL: https://codereview.chromium.org/772203002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293250 0039d316-1c4b-4281-b951-d872f2087c98
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
Nico Weber
Rico Wind
Ryan Tseng
pauljensen@chromium.org
dsansome@chromium.org
hinoka@chromium.org
ricow@chromium.org
boliu@chromium.org
nparker@chromium.org
primiano@chromium.org
mmoss@chromium.org
dpranke@chromium.org
ojan@chromium.org
hinoka@google.com
hinoka@chromium.org
brettw@chromium.org
scottmg@chromium.org
petermayo@chromium.org