DevFW-CICD/ingress-nginx-helm
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update go dependencies

Browse source
This commit is contained in:
Manuel Alejandro de Brito Fontes 2018-12-05 13:27:09 -03:00
parent 432f534383
commit f4a4daed84
1299 changed files with 71186 additions and 91183 deletions
Download patch file Download diff file Expand all files Collapse all files

12
vendor/google.golang.org/api/.gitignore generated vendored Normal file
View file

@ -0,0 +1,12 @@
_obj/
*_testmain.go
clientid.dat
clientsecret.dat
/google-api-go-generator/google-api-go-generator
*.6
*.8
*~
*.out
*.test
*.exe

1
vendor/google.golang.org/api/.hgtags generated vendored Normal file
View file

@ -0,0 +1 @@
b571b553f8c057cb6952ce817dfb09b6e34a8c0b release

10
vendor/google.golang.org/api/AUTHORS generated vendored Normal file
View file

@ -0,0 +1,10 @@
# This is the official list of authors for copyright purposes.
# This file is distinct from the CONTRIBUTORS files.
# See the latter for an explanation.
# Names should be added to this file as
# Name or Organization <email address>
# The email address is not required for organizations.
# Please keep the list sorted.
Google Inc.

484
vendor/google.golang.org/api/CONTRIBUTING.md generated vendored Normal file
View file

@ -0,0 +1,484 @@
# Contributing to the Google API Go Client
## Master git repo
Our master git repo is https://code.googlesource.com/google-api-go-client
## Pull Requests
We do **NOT** use Github pull requests. We use Gerrit instead
with the same workflow as Go. See below.
## The source tree
Most of this project is auto-generated.
The notable directories which are not auto-generated:
```
google-api-go-generator/ -- the generator itself
googleapi/ -- shared common code, used by auto-generated code
examples/ -- sample code
```
# Contribution Guidelines
## Introduction
This document explains how to contribute changes to the google-api-go-client project.
## Testing redux
You've written and tested your code, but
before sending code out for review, run all the tests for the whole
tree to make sure the changes don't break other packages or programs:
```
$ make cached
$ go test ./...
...
ok google.golang.org/api/google-api-go-generator 0.226s
ok google.golang.org/api/googleapi 0.015s
...
```
Ideally, you will add unit tests to one of the above directories to
demonstrate the changes you are making and include the tests with your
code review.
## Code review
Changes to google-api-go-client must be reviewed before they are submitted,
no matter who makes the change.
A custom git command called `git-codereview`,
discussed below, helps manage the code review process through a Google-hosted
[instance](https://code-review.googlesource.com/) of the code review
system called [Gerrit](https://code.google.com/p/gerrit/).
### Set up authentication for code review
The Git code hosting server and Gerrit code review server both use a Google
Account to authenticate. You therefore need a Google Account to proceed.
(If you can use the account to
[sign in at google.com](https://www.google.com/accounts/Login),
you can use it to sign in to the code review server.)
The email address you use with the code review system
needs to be added to the [`CONTRIBUTORS`](/CONTRIBUTORS) file
with your first code review.
You can [create a Google Account](https://www.google.com/accounts/NewAccount)
associated with any address where you receive email.
Visit the site [code.googlesource.com](https://code.googlesource.com)
and log in using your Google Account.
Click on the "Generate Password" link that appears at the top of the page.
Click the radio button that says "Only `code.googlesource.com`"
to use this authentication token only for the google-api-go-client project.
Further down the page is a box containing commands to install
the authentication cookie in file called `.gitcookies` in your home
directory.
Copy the text for the commands into a Unix shell window to execute it.
That will install the authentication token.
(If you are on a Windows computer, you should instead follow the instructions
in the yellow box to run the command.)
### Register with Gerrit
Now that you have a Google account and the authentication token,
you need to register your account with Gerrit, the code review system.
To do this, visit [golang.org/cl](https://golang.org/cl)
and log in using the same Google Account you used above.
That is all that is required.
### Install the git-codereview command
Now install the `git-codereview` command by running,
```
go get -u golang.org/x/review/git-codereview
```
Make sure `git-codereview` is installed in your shell path, so that the
`git` command can find it. Check that
```
$ git codereview help
```
prints help text, not an error.
Note to Git aficionados: The `git-codereview` command is not required to
upload and manage Gerrit code reviews. For those who prefer plain Git, the text
below gives the Git equivalent of each git-codereview command. If you do use plain
Git, note that you still need the commit hooks that the git-codereview command
configures; those hooks add a Gerrit `Change-Id` line to the commit
message and check that all Go source files have been formatted with gofmt. Even
if you intend to use plain Git for daily work, install the hooks in a new Git
checkout by running `git-codereview hooks`.
### Set up git aliases
The `git-codereview` command can be run directly from the shell
by typing, for instance,
```
$ git codereview sync
```
but it is more convenient to set up aliases for `git-codereview`'s own
subcommands, so that the above becomes,
```
$ git sync
```
The `git-codereview` subcommands have been chosen to be distinct from
Git's own, so it's safe to do so.
The aliases are optional, but in the rest of this document we will assume
they are installed.
To install them, copy this text into your Git configuration file
(usually `.gitconfig` in your home directory):
```
[alias]
change = codereview change
gofmt = codereview gofmt
mail = codereview mail
pending = codereview pending
submit = codereview submit
sync = codereview sync
```
### Understanding the git-codereview command
After installing the `git-codereview` command, you can run
```
$ git codereview help
```
to learn more about its commands.
You can also read the [command documentation](https://godoc.org/golang.org/x/review/git-codereview).
### Switch to the master branch
New changes should
only be made based on the master branch.
Before making a change, make sure you start on the master branch:
```
$ git checkout master
$ git sync
````
(In Git terms, `git sync` runs
`git pull -r`.)
### Make a change
The entire checked-out tree is writable.
Once you have edited files, you must tell Git that they have been modified.
You must also tell Git about any files that are added, removed, or renamed files.
These operations are done with the usual Git commands,
`git add`,
`git rm`,
and
`git mv`.
If you wish to checkpoint your work, or are ready to send the code out for review, run
```
$ git change <branch>
```
from any directory in your google-api-go-client repository to commit the changes so far.
The name `<branch>` is an arbitrary one you choose to identify the
local branch containing your changes.
(In Git terms, `git change <branch>`
runs `git checkout -b branch`,
then `git branch --set-upstream-to origin/master`,
then `git commit`.)
Git will open a change description file in your editor.
(It uses the editor named by the `$EDITOR` environment variable,
`vi` by default.)
The file will look like:
```
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch foo
# Changes not staged for commit:
# modified: editedfile.go
#
```
At the beginning of this file is a blank line; replace it
with a thorough description of your change.
The first line of the change description is conventionally a one-line
summary of the change, prefixed by `google-api-go-client:`,
and is used as the subject for code review mail.
The rest of the
description elaborates and should provide context for the
change and explain what it does.
If there is a helpful reference, mention it here.
After editing, the template might now read:
```
math: improved Sin, Cos and Tan precision for very large arguments
The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.
The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm
Fixes #54
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch foo
# Changes not staged for commit:
# modified: editedfile.go
#
```
The commented section of the file lists all the modified files in your client.
It is best to keep unrelated changes in different change lists,
so if you see a file listed that should not be included, abort
the command and move that file to a different branch.
The special notation "Fixes #54" associates the change with issue 54 in the
[google-api-go-client issue tracker](https://github.com/google/google-api-go-client/issues/54).
When this change is eventually submitted, the issue
tracker will automatically mark the issue as fixed.
(There are several such conventions, described in detail in the
[GitHub Issue Tracker documentation](https://help.github.com/articles/closing-issues-via-commit-messages/).)
Once you have finished writing the commit message,
save the file and exit the editor.
If you wish to do more editing, re-stage your changes using
`git add`, and then run
```
$ git change
```
to update the change description and incorporate the staged changes. The
change description contains a `Change-Id` line near the bottom,
added by a Git commit hook during the initial
`git change`.
That line is used by Gerrit to match successive uploads of the same change.
Do not edit or delete it.
(In Git terms, `git change` with no branch name
runs `git commit --amend`.)
### Mail the change for review
Once the change is ready, mail it out for review:
```
$ git mail
```
You can specify a reviewer or CC interested parties
using the `-r` or `-cc` options.
Both accept a comma-separated list of email addresses:
```
$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
```
Unless explicitly told otherwise, such as in the discussion leading
up to sending in the change list, please specify
`bradfitz@golang.org`, `gmlewis@google.com`, or
`mcgreevy@golang.org` as a reviewer.
(In Git terms, `git mail` pushes the local committed
changes to Gerrit using `git push origin HEAD:refs/for/master`.)
If your change relates to an open issue, please add a comment to the issue
announcing your proposed fix, including a link to your CL.
The code review server assigns your change an issue number and URL,
which `git mail` will print, something like:
```
remote: New Changes:
remote: https://code-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
```
### Reviewing code
Running `git mail` will send an email to you and the
reviewers asking them to visit the issue's URL and make comments on the change.
When done, the reviewer adds comments through the Gerrit user interface
and clicks "Reply" to send comments back.
You will receive a mail notification when this happens.
You must reply through the web interface.
### Revise and upload
You must respond to review comments through the web interface.
When you have revised the code and are ready for another round of review,
stage those changes and use `git change` to update the
commit.
To send the update change list for another round of review,
run `git mail` again.
The reviewer can comment on the new copy, and the process repeats.
The reviewer approves the change by giving it a positive score
(+1 or +2) and replying `LGTM`: looks good to me.
You can see a list of your pending changes by running
`git pending`, and switch between change branches with
`git change <branch>`.
### Synchronize your client
While you were working, others might have submitted changes to the repository.
To update your local branch, run
```
$ git sync
```
(In git terms, `git sync` runs
`git pull -r`.)
If files you were editing have changed, Git does its best to merge the
remote changes into your local changes.
It may leave some files to merge by hand.
For example, suppose you have edited `sin.go` but
someone else has committed an independent change.
When you run `git sync`,
you will get the (scary-looking) output:
```
$ git sync
Failed to merge in the changes.
Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
The copy of the patch that failed is found in:
/home/you/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
```
If this happens, run
```
$ git status
```
to see which files failed to merge.
The output will look something like this:
```
rebase in progress; onto a24c3eb
You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
_both modified: sin.go_
```
The only important part in that transcript is the italicized "both modified"
line: Git failed to merge your changes with the conflicting change.
When this happens, Git leaves both sets of edits in the file,
with conflicts marked by `<<<<<<<` and
`>>>>>>>`.
It is now your job to edit the file to combine them.
Continuing the example, searching for those strings in `sin.go`
might turn up:
```
arg = scale(arg)
<<<<<<< HEAD
if arg > 1e9 {
=======
if arg > 1e10 {
>>>>>>> mcgillicutty
largeReduce(arg)
```
Git doesn't show it, but suppose the original text that both edits
started with was 1e8; you changed it to 1e10 and the other change to 1e9,
so the correct answer might now be 1e10. First, edit the section
to remove the markers and leave the correct code:
```
arg = scale(arg)
if arg > 1e10 {
largeReduce(arg)
```
Then tell Git that the conflict is resolved by running
```
$ git add sin.go
```
If you had been editing the file, say for debugging, but do not
care to preserve your changes, you can run
`git reset HEAD sin.go`
to abandon your changes.
Then run `git rebase --continue` to
restore the change commit.
### Reviewing code by others
You can import a change proposed by someone else into your local Git repository.
On the Gerrit review page, click the "Download ▼" link in the upper right
corner, copy the "Checkout" command and run it from your local Git repo.
It should look something like this:
```
$ git fetch https://code.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
```
To revert, change back to the branch you were working in.
### Submit the change after the review
After the code has been `LGTM`'ed, an approver may
submit it to the master branch using the Gerrit UI.
There is a "Submit" button on the web page for the change
that appears once the change is approved (marked +2).
This checks the change into the repository.
The change description will include a link to the code review,
and the code review will be updated with a link to the change
in the repository.
Since the method used to integrate the changes is "Cherry Pick",
the commit hashes in the repository will be changed by
the submit operation.
### More information
In addition to the information here, the Go community maintains a [CodeReview](https://golang.org/wiki/CodeReview) wiki page.
Feel free to contribute to this page as you learn the review process.
## Contributors
Files in the google-api-go-client repository don't list author names,
both to avoid clutter and to avoid having to keep the lists up to date.
Instead, please add your name to the [`CONTRIBUTORS`](/CONTRIBUTORS)
file as your first code review, keeping the names in sorted order.

55
vendor/google.golang.org/api/CONTRIBUTORS generated vendored Normal file
View file

@ -0,0 +1,55 @@
# This is the official list of people who can contribute
# (and typically have contributed) code to the repository.
# The AUTHORS file lists the copyright holders; this file
# lists people. For example, Google employees are listed here
# but not in AUTHORS, because Google holds the copyright.
#
# The submission process automatically checks to make sure
# that people submitting code are listed in this file (by email address).
#
# Names should be added to this file only after verifying that
# the individual or the individual's organization has agreed to
# the appropriate Contributor License Agreement, found here:
#
# https://cla.developers.google.com/about/google-individual
# https://cla.developers.google.com/about/google-corporate
#
# The CLA can be filled out on the web:
#
# https://cla.developers.google.com/
#
# When adding J Random Contributor's name to this file,
# either J's name or J's organization's name should be
# added to the AUTHORS file, depending on whether the
# individual or corporate CLA was used.
# Names should be added to this file like so:
# Name <email address>
#
# An entry with two email addresses specifies that the
# first address should be used in the submit logs and
# that the second address should be recognized as the
# same person when interacting with Rietveld.
# Please keep the list sorted.
Alain Vongsouvanhalainv <alainv@google.com>
Andrew Gerrand <adg@golang.org>
Brad Fitzpatrick <bradfitz@golang.org>
Eric Koleda <ekoleda+devrel@googlers.com>
Francesc Campoy <campoy@golang.org>
Garrick Evans <garrick@google.com>
Glenn Lewis <gmlewis@google.com>
Ivan Krasin <krasin@golang.org>
Jason Hall <jasonhall@google.com>
Johan Euphrosine <proppy@google.com>
Kostik Shtoyk <kostik@google.com>
Kunpei Sakai <namusyaka@gmail.com>
Matthew Whisenhunt <matt.whisenhunt@gmail.com>
Michael McGreevy <mcgreevy@golang.org>
Nick Craig-Wood <nickcw@gmail.com>
Robbie Trencheny <me@robbiet.us>
Ross Light <light@google.com>
Sarah Adams <shadams@google.com>
Scott Van Woudenberg <scottvw@google.com>
Takashi Matsuo <tmatsuo@google.com>

146
vendor/google.golang.org/api/GettingStarted.md generated vendored Normal file
View file

@ -0,0 +1,146 @@
# Getting Started with the Google APIs for Go
## Getting Started
This is a quick walk-through of how to get started with the Google APIs for Go.
## Background
The first thing to understand is that the Google API libraries are auto-generated for
each language, including Go, so they may not feel like 100% natural for any language.
The Go versions are pretty natural, but please forgive any small non-idiomatic things.
(Suggestions welcome, though!)
## Installing
Pick an API and a version of that API to install.
You can find the complete list by looking at the
[directories here](https://github.com/google/google-api-go-client/tree/master/).
For example, let's install the
[urlshortener's version 1 API](https://godoc.org/google.golang.org/api/urlshortener/v1):
```
$ go get -u google.golang.org/api/urlshortener/v1
```
Now it's ready for use in your code.
## Using
Once you've installed a library, you import it like this:
```go
package main
import (
"context"
"golang.org/x/oauth2"
"golang.org/x/oauth2/google"
"google.golang.org/api/urlshortener/v1"
)
```
The package name, if you don't override it on your import line, is the name of the
API without the version number. In the case above, just `urlshortener`.
## Instantiating
Each API has a `New` function taking an `*http.Client` and returning an API-specific `*Service`.
You create the service like:
```go
svc, err := urlshortener.New(httpClient)
```
## OAuth HTTP Client
The HTTP client you pass in to the service must be one that automatically adds
Google-supported Authorization information to the requests.
There are several ways to do authentication. They will all involve the package
[golang.org/x/oauth2](https://godoc.org/golang.org/x/oauth2) in some way.
### 3-legged OAuth
For 3-legged OAuth (your application redirecting a user through a website to get a
token giving your application access to that user's resources), you will need to
create an oauth2.Config,
```go
var config = &oauth2.Config{
ClientID: "", // from https://console.developers.google.com/project/<your-project-id>/apiui/credential
ClientSecret: "", // from https://console.developers.google.com/project/<your-project-id>/apiui/credential
Endpoint: google.Endpoint,
Scopes: []string{urlshortener.UrlshortenerScope},
}
```
... and then use the AuthCodeURL, Exchange, and Client methods on it.
For an example, see: https://godoc.org/golang.org/x/oauth2#example-Config
For the redirect URL, see
https://developers.google.com/identity/protocols/OAuth2InstalledApp#choosingredirecturi
### Service Accounts
To use a Google service account, or the GCE metadata service, see
the [golang.org/x/oauth2/google](https://godoc.org/golang.org/x/oauth2/google) package.
In particular, see [google.DefaultClient](https://godoc.org/golang.org/x/oauth2/google#DefaultClient).
### Using API Keys
Some APIs require passing API keys from your application.
To do this, you can use
[transport.APIKey](https://godoc.org/google.golang.org/api/googleapi/transport#APIKey):
```go
ctx := context.WithValue(context.Background(), oauth2.HTTPClient, &http.Client{
Transport: &transport.APIKey{Key: developerKey},
})
oauthConfig := &oauth2.Config{ .... }
var token *oauth2.Token = .... // via cache, or oauthConfig.Exchange
httpClient := oauthConfig.Client(ctx, token)
svc, err := urlshortener.New(httpClient)
...
```
## Using the Service
Each service contains zero or more methods and zero or more sub-services.
The sub-services related to a specific type of "Resource".
Those sub-services then contain their own methods.
For instance, the urlshortener API has just the "Url" sub-service:
```go
url, err := svc.Url.Get(shortURL).Do()
if err != nil {
...
}
fmt.Printf("The URL %s goes to %s\n", shortURL, url.LongUrl)
```
For a more complete example, see
[urlshortener.go](https://github.com/google/google-api-go-client/tree/master/examples/urlshortener.go)
in the [examples directory](https://github.com/google/google-api-go-client/tree/master/examples/).
(the examples use some functions in `main.go` in the same directory)
## Error Handling
Most errors returned by the `Do` methods of these clients will be of type
[`googleapi.Error`](https://godoc.org/google.golang.org/api/googleapi#Error).
Use a type assertion to obtain the HTTP status code and other properties of the
error:
```go
url, err := svc.Url.Get(shortURL).Do()
if err != nil {
if e, ok := err.(*googleapi.Error); ok && e.Code == http.StatusNotFound {
...
}
}
```

27
vendor/google.golang.org/api/LICENSE generated vendored Normal file
View file

@ -0,0 +1,27 @@
Copyright (c) 2011 Google Inc. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

13
vendor/google.golang.org/api/NOTES generated vendored Normal file
View file

@ -0,0 +1,13 @@
Discovery Service:
https://developers.google.com/discovery/
https://developers.google.com/discovery/v1/reference/
The "type" key:
http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.1
The "format" key:
http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.23
https://developers.google.com/discovery/v1/type-format
Google JSON format docs:
http://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml

103
vendor/google.golang.org/api/README.md generated vendored Normal file
View file

@ -0,0 +1,103 @@
# Google APIs Client Library for Go
## Getting Started
```
$ go get google.golang.org/api/tasks/v1
$ go get google.golang.org/api/moderator/v1
$ go get google.golang.org/api/urlshortener/v1
... etc ...
```
and using:
```go
package main
import (
"net/http"
"google.golang.org/api/urlshortener/v1"
)
func main() {
svc, err := urlshortener.New(http.DefaultClient)
// ...
}
```
* For a longer tutorial, see the [Getting Started guide](https://github.com/google/google-api-go-client/blob/master/GettingStarted.md).
* For examples, see the [examples directory](https://github.com/google/google-api-go-client/tree/master/examples).
* For support, use the [golang-nuts](https://groups.google.com/group/golang-nuts) mailing list.
## Status
[![GoDoc](https://godoc.org/google.golang.org/api?status.svg)](https://godoc.org/google.golang.org/api)
These are auto-generated Go libraries from the Google Discovery Service's JSON description files of the available "new style" Google APIs.
Due to the auto-generated nature of this collection of libraries, complete APIs or specific versions can appear or go away without notice.
As a result, you should always locally vendor any API(s) that your code relies upon.
These client libraries are officially supported by Google. However, the libraries are considered complete and are in maintenance mode. This means that we will address critical bugs and security issues but will not add any new features.
If you're working with Google Cloud Platform APIs such as Datastore or Pub/Sub,
consider using the
[Cloud Client Libraries for Go](https://github.com/GoogleCloudPlatform/google-cloud-go)
instead. These are the new and
idiomatic Go libraries targeted specifically at Google Cloud Platform Services.
The generator itself and the code it produces are beta. Some APIs are
alpha/beta, and indicated as such in the import path (e.g.,
"google.golang.org/api/someapi/v1alpha").
## Application Default Credentials Example
Application Default Credentials provide a simplified way to obtain credentials
for authenticating with Google APIs.
The Application Default Credentials authenticate as the application itself,
which make them great for working with Google Cloud APIs like Storage or
Datastore. They are the recommended form of authentication when building
applications that run on Google Compute Engine or Google App Engine.
Default credentials are provided by the `golang.org/x/oauth2/google` package. To use them, add the following import:
```go
import "golang.org/x/oauth2/google"
```
Some credentials types require you to specify scopes, and service entry points may not inject them. If you encounter this situation you may need to specify scopes as follows:
```go
import (
"context"
"golang.org/x/oauth2/google"
"google.golang.org/api/compute/v1"
)
func main() {
// Use oauth2.NoContext if there isn't a good context to pass in.
ctx := context.Background()
client, err := google.DefaultClient(ctx, compute.ComputeScope)
if err != nil {
//...
}
computeService, err := compute.New(client)
if err != nil {
//...
}
}
```
If you need a `oauth2.TokenSource`, use the `DefaultTokenSource` function:
```go
ts, err := google.DefaultTokenSource(ctx, scope1, scope2, ...)
if err != nil {
//...
}
client := oauth2.NewClient(ctx, ts)
```
See also: [golang.org/x/oauth2/google](https://godoc.org/golang.org/x/oauth2/google) package documentation.

2
vendor/google.golang.org/api/TODO generated vendored Normal file
View file

@ -0,0 +1,2 @@
Moved to:
https://github.com/google/google-api-go-client/issues

3363
vendor/google.golang.org/api/api-list.json generated vendored Normal file
View file

File diff suppressed because it is too large Load diff

0
vendor/google.golang.org/api/key.json.enc generated vendored Normal file
View file

349
vendor/google.golang.org/api/support/bundler/bundler.go generated vendored Normal file
View file

@ -0,0 +1,349 @@
// Copyright 2016 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Package bundler supports bundling (batching) of items. Bundling amortizes an
// action with fixed costs over multiple items. For example, if an API provides
// an RPC that accepts a list of items as input, but clients would prefer
// adding items one at a time, then a Bundler can accept individual items from
// the client and bundle many of them into a single RPC.
//
// This package is experimental and subject to change without notice.
package bundler
import (
"context"
"errors"
"math"
"reflect"
"sync"
"time"
"golang.org/x/sync/semaphore"
)
const (
DefaultDelayThreshold = time.Second
DefaultBundleCountThreshold = 10
DefaultBundleByteThreshold = 1e6 // 1M
DefaultBufferedByteLimit = 1e9 // 1G
)
var (
// ErrOverflow indicates that Bundler's stored bytes exceeds its BufferedByteLimit.
ErrOverflow = errors.New("bundler reached buffered byte limit")
// ErrOversizedItem indicates that an item's size exceeds the maximum bundle size.
ErrOversizedItem = errors.New("item size exceeds bundle byte limit")
)
// A Bundler collects items added to it into a bundle until the bundle
// exceeds a given size, then calls a user-provided function to handle the bundle.
type Bundler struct {
// Starting from the time that the first message is added to a bundle, once
// this delay has passed, handle the bundle. The default is DefaultDelayThreshold.
DelayThreshold time.Duration
// Once a bundle has this many items, handle the bundle. Since only one
// item at a time is added to a bundle, no bundle will exceed this
// threshold, so it also serves as a limit. The default is
// DefaultBundleCountThreshold.
BundleCountThreshold int
// Once the number of bytes in current bundle reaches this threshold, handle
// the bundle. The default is DefaultBundleByteThreshold. This triggers handling,
// but does not cap the total size of a bundle.
BundleByteThreshold int
// The maximum size of a bundle, in bytes. Zero means unlimited.
BundleByteLimit int
// The maximum number of bytes that the Bundler will keep in memory before
// returning ErrOverflow. The default is DefaultBufferedByteLimit.
BufferedByteLimit int
// The maximum number of handler invocations that can be running at once.
// The default is 1.
HandlerLimit int
handler func(interface{}) // called to handle a bundle
itemSliceZero reflect.Value // nil (zero value) for slice of items
flushTimer *time.Timer // implements DelayThreshold
mu sync.Mutex
sem *semaphore.Weighted // enforces BufferedByteLimit
semOnce sync.Once
curBundle bundle // incoming items added to this bundle
// Each bundle is assigned a unique ticket that determines the order in which the
// handler is called. The ticket is assigned with mu locked, but waiting for tickets
// to be handled is done via mu2 and cond, below.
nextTicket uint64 // next ticket to be assigned
mu2 sync.Mutex
cond *sync.Cond
nextHandled uint64 // next ticket to be handled
// In this implementation, active uses space proportional to HandlerLimit, and
// waitUntilAllHandled takes time proportional to HandlerLimit each time an acquire
// or release occurs, so large values of HandlerLimit max may cause performance
// issues.
active map[uint64]bool // tickets of bundles actively being handled
}
type bundle struct {
items reflect.Value // slice of item type
size int // size in bytes of all items
}
// NewBundler creates a new Bundler.
//
// itemExample is a value of the type that will be bundled. For example, if you
// want to create bundles of *Entry, you could pass &Entry{} for itemExample.
//
// handler is a function that will be called on each bundle. If itemExample is
// of type T, the argument to handler is of type []T. handler is always called
// sequentially for each bundle, and never in parallel.
//
// Configure the Bundler by setting its thresholds and limits before calling
// any of its methods.
func NewBundler(itemExample interface{}, handler func(interface{})) *Bundler {
b := &Bundler{
DelayThreshold: DefaultDelayThreshold,
BundleCountThreshold: DefaultBundleCountThreshold,
BundleByteThreshold: DefaultBundleByteThreshold,
BufferedByteLimit: DefaultBufferedByteLimit,
HandlerLimit: 1,
handler: handler,
itemSliceZero: reflect.Zero(reflect.SliceOf(reflect.TypeOf(itemExample))),
active: map[uint64]bool{},
}
b.curBundle.items = b.itemSliceZero
b.cond = sync.NewCond(&b.mu2)
return b
}
func (b *Bundler) initSemaphores() {
// Create the semaphores lazily, because the user may set limits
// after NewBundler.
b.semOnce.Do(func() {
b.sem = semaphore.NewWeighted(int64(b.BufferedByteLimit))
})
}
// Add adds item to the current bundle. It marks the bundle for handling and
// starts a new one if any of the thresholds or limits are exceeded.
//
// If the item's size exceeds the maximum bundle size (Bundler.BundleByteLimit), then
// the item can never be handled. Add returns ErrOversizedItem in this case.
//
// If adding the item would exceed the maximum memory allowed
// (Bundler.BufferedByteLimit) or an AddWait call is blocked waiting for
// memory, Add returns ErrOverflow.
//
// Add never blocks.
func (b *Bundler) Add(item interface{}, size int) error {
// If this item exceeds the maximum size of a bundle,
// we can never send it.
if b.BundleByteLimit > 0 && size > b.BundleByteLimit {
return ErrOversizedItem
}
// If adding this item would exceed our allotted memory
// footprint, we can't accept it.
// (TryAcquire also returns false if anything is waiting on the semaphore,
// so calls to Add and AddWait shouldn't be mixed.)
b.initSemaphores()
if !b.sem.TryAcquire(int64(size)) {
return ErrOverflow
}
b.add(item, size)
return nil
}
// add adds item to the current bundle. It marks the bundle for handling and
// starts a new one if any of the thresholds or limits are exceeded.
func (b *Bundler) add(item interface{}, size int) {
b.mu.Lock()
defer b.mu.Unlock()
// If adding this item to the current bundle would cause it to exceed the
// maximum bundle size, close the current bundle and start a new one.
if b.BundleByteLimit > 0 && b.curBundle.size+size > b.BundleByteLimit {
b.startFlushLocked()
}
// Add the item.
b.curBundle.items = reflect.Append(b.curBundle.items, reflect.ValueOf(item))
b.curBundle.size += size
// Start a timer to flush the item if one isn't already running.
// startFlushLocked clears the timer and closes the bundle at the same time,
// so we only allocate a new timer for the first item in each bundle.
// (We could try to call Reset on the timer instead, but that would add a lot
// of complexity to the code just to save one small allocation.)
if b.flushTimer == nil {
b.flushTimer = time.AfterFunc(b.DelayThreshold, b.Flush)
}
// If the current bundle equals the count threshold, close it.
if b.curBundle.items.Len() == b.BundleCountThreshold {
b.startFlushLocked()
}
// If the current bundle equals or exceeds the byte threshold, close it.
if b.curBundle.size >= b.BundleByteThreshold {
b.startFlushLocked()
}
}
// AddWait adds item to the current bundle. It marks the bundle for handling and
// starts a new one if any of the thresholds or limits are exceeded.
//
// If the item's size exceeds the maximum bundle size (Bundler.BundleByteLimit), then
// the item can never be handled. AddWait returns ErrOversizedItem in this case.
//
// If adding the item would exceed the maximum memory allowed (Bundler.BufferedByteLimit),
// AddWait blocks until space is available or ctx is done.
//
// Calls to Add and AddWait should not be mixed on the same Bundler.
func (b *Bundler) AddWait(ctx context.Context, item interface{}, size int) error {
// If this item exceeds the maximum size of a bundle,
// we can never send it.
if b.BundleByteLimit > 0 && size > b.BundleByteLimit {
return ErrOversizedItem
}
// If adding this item would exceed our allotted memory footprint, block
// until space is available. The semaphore is FIFO, so there will be no
// starvation.
b.initSemaphores()
if err := b.sem.Acquire(ctx, int64(size)); err != nil {
return err
}
// Here, we've reserved space for item. Other goroutines can call AddWait
// and even acquire space, but no one can take away our reservation
// (assuming sem.Release is used correctly). So there is no race condition
// resulting from locking the mutex after sem.Acquire returns.
b.add(item, size)
return nil
}
// Flush invokes the handler for all remaining items in the Bundler and waits
// for it to return.
func (b *Bundler) Flush() {
b.mu.Lock()
b.startFlushLocked()
// Here, all bundles with tickets < b.nextTicket are
// either finished or active. Those are the ones
// we want to wait for.
t := b.nextTicket
b.mu.Unlock()
b.initSemaphores()
b.waitUntilAllHandled(t)
}
func (b *Bundler) startFlushLocked() {
if b.flushTimer != nil {
b.flushTimer.Stop()
b.flushTimer = nil
}
if b.curBundle.items.Len() == 0 {
return
}
// Here, both semaphores must have been initialized.
bun := b.curBundle
b.curBundle = bundle{items: b.itemSliceZero}
ticket := b.nextTicket
b.nextTicket++
go func() {
defer func() {
b.sem.Release(int64(bun.size))
b.release(ticket)
}()
b.acquire(ticket)
b.handler(bun.items.Interface())
}()
}
// acquire blocks until ticket is the next to be served, then returns. In order for N
// acquire calls to return, the tickets must be in the range [0, N). A ticket must
// not be presented to acquire more than once.
func (b *Bundler) acquire(ticket uint64) {
b.mu2.Lock()
defer b.mu2.Unlock()
if ticket < b.nextHandled {
panic("bundler: acquire: arg too small")
}
for !(ticket == b.nextHandled && len(b.active) < b.HandlerLimit) {
b.cond.Wait()
}
// Here,
// ticket == b.nextHandled: the caller is the next one to be handled;
// and len(b.active) < b.HandlerLimit: there is space available.
b.active[ticket] = true
b.nextHandled++
// Broadcast, not Signal: although at most one acquire waiter can make progress,
// there might be waiters in waitUntilAllHandled.
b.cond.Broadcast()
}
// If a ticket is used for a call to acquire, it must later be passed to release. A
// ticket must not be presented to release more than once.
func (b *Bundler) release(ticket uint64) {
b.mu2.Lock()
defer b.mu2.Unlock()
if !b.active[ticket] {
panic("bundler: release: not an active ticket")
}
delete(b.active, ticket)
b.cond.Broadcast()
}
// waitUntilAllHandled blocks until all tickets < n have called release, meaning
// all bundles with tickets < n have been handled.
func (b *Bundler) waitUntilAllHandled(n uint64) {
// Proof of correctness of this function.
// "N is acquired" means acquire(N) has returned.
// "N is released" means release(N) has returned.
// 1. If N is acquired, N-1 is acquired.
// Follows from the loop test in acquire, and the fact
// that nextHandled is incremented by 1.
// 2. If nextHandled >= N, then N-1 is acquired.
// Because we only increment nextHandled to N after N-1 is acquired.
// 3. If nextHandled >= N, then all n < N is acquired.
// Follows from #1 and #2.
// 4. If N is acquired and N is not in active, then N is released.
// Because we put N in active before acquire returns, and only
// remove it when it is released.
// Let min(active) be the smallest member of active, or infinity if active is empty.
// 5. If nextHandled >= N and N <= min(active), then all n < N is released.
// From nextHandled >= N and #3, all n < N is acquired.
// N <= min(active) implies n < min(active) for all n < N. So all n < N is not in active.
// So from #4, all n < N is released.
// The loop test below is the antecedent of #5.
b.mu2.Lock()
defer b.mu2.Unlock()
for !(b.nextHandled >= n && n <= min(b.active)) {
b.cond.Wait()
}
}
// min returns the minimum value of the set s, or the largest uint64 if
// s is empty.
func min(s map[uint64]bool) uint64 {
var m uint64 = math.MaxUint64
for n := range s {
if n < m {
m = n
}
}
return m
}