Remove remaining references to vendor
This commit is contained in:
parent
83d5f77495
commit
8b089dc441
@ -1,7 +1,4 @@
|
||||
run:
|
||||
skip-dirs:
|
||||
- vendor
|
||||
|
||||
timeout: 2m
|
||||
|
||||
linters-settings:
|
||||
|
@ -41,8 +41,6 @@ $ protoc --go_out=import_path=dexapi:. api.proto
|
||||
|
||||
Client programs can then be written using the generated code. A Go client which uses dex's internally generated code might look like the following:
|
||||
|
||||
__NOTE:__ Because dex has the `google.golang.org/grpc` package in its `vendor` directory, gRPC code in `github.com/dexidp/dex/api` refers to the vendored copy, not copies in a developers GOPATH. Clients must either regenerate the gRPC Go code or vendor dex and remove its `vendor` directory to run this program.
|
||||
|
||||
```
|
||||
package main
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
## Go modules
|
||||
|
||||
Dex uses [Go modules][go-modules] to manage its [`vendor` directory][go-vendor]. Go 1.11 or higher is recommended. While Go 1.12 is expected to finalize the Go modules feature, with Go 1.11 you should [activate the Go modules feature][go-modules-activate] before interacting with Go modules.
|
||||
Dex uses [Go modules][go-modules] to manage its dependencies. Go 1.11 or higher is recommended. While Go 1.12 is expected to finalize the Go modules feature, with Go 1.11 you should [activate the Go modules feature][go-modules-activate] before interacting with Go modules.
|
||||
|
||||
Here is one way to activate the Go modules feature with Go 1.11.
|
||||
|
||||
@ -21,22 +21,9 @@ To add a new dependency to dex or update an existing one:
|
||||
* Run `go mod tidy -v`. This is a good option if you do not wish to immediately pin to a specific Semantic Version or commit.
|
||||
* Run, for example, `go get <package-name>@<commit-hash>`. This is a good option when you want to immediately pin to a specific Semantic Version or commit.
|
||||
* Manually update `go.mod`. If one of the two options above doesn't suit you, do this -- but very carefully.
|
||||
3. Create a git commit to reflect your code (not vendor) changes. See below for tips on composing commits.
|
||||
4. Once `go.mod` describes the desired state and you've create a commit for that change, run `make revendor` to update `go.mod`, `go.sum` and `vendor`. This calls `go mod tidy -v`, `go mod vendor -v` and `go mod verify`.
|
||||
5. Create a git commit to reflect the changes made by `make revendor`. Again, see below for tips on composing commits.
|
||||
3. Create a git commit to reflect your code changes.
|
||||
|
||||
## Composing commits
|
||||
|
||||
When composing commits make sure that updates to `vendor` are in a separate commit from the main changes. GitHub's UI makes commits with a large number of changes unreviewable.
|
||||
|
||||
Commit histories should look like the following:
|
||||
|
||||
```
|
||||
connector/ldap: add a LDAP connector
|
||||
vendor: revendor
|
||||
```
|
||||
|
||||
[go-modules]: https://github.com/golang/go/wiki/Modules
|
||||
[go-modules-activate]: https://github.com/golang/go/wiki/Modules#how-to-install-and-activate-module-support
|
||||
[go-vendor]: https://golang.org/cmd/go/#hdr-Vendor_Directories
|
||||
[module-aware-go-get]: https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get
|
||||
|
14
vendor.go
14
vendor.go
@ -1,14 +0,0 @@
|
||||
// +build vendor
|
||||
|
||||
package main
|
||||
|
||||
// This file exists to trick "go mod vendor" to include "main" packages.
|
||||
// It is not expected to build, the build tag above is only to prevent this
|
||||
// file from being included in builds.
|
||||
|
||||
import (
|
||||
_ "github.com/golang/protobuf/protoc-gen-go"
|
||||
_ "golang.org/x/lint/golint"
|
||||
)
|
||||
|
||||
func main() {}
|
Reference in New Issue
Block a user