Skip to content

Commit 1014a81

Browse files
jsharolandshoemaker
authored andcommitted
Switch to modules (letsencrypt#4211)
Because the package versions in go.mod match what we use in Godeps.json, there are no substantive code diffs. However, there are some tiny differences resulting from how go mod vendors things differently than godep: go mod does not preserve executable permissions on shell scripts Some packages have import lines like: package ocsp // import "golang.org/x/crypto/ocsp" godep used to remove the comment from these lines, but go mod vendor does not. This introduces several indirect dependencies that we didn't have before. This is because godep used to operate at a package level, but go mod operates at a module (~= repository) level. So if we used a given repository, but didn't use all of its packages, we wouldn't previously care about the transitive dependencies of the packages we weren't using. However, in the go mod world, once we care about the repository, we care about all of that repository's transitive dependencies. AFAICT this doesn't affect vendoring. Fixes letsencrypt#4116
1 parent ea9871d commit 1014a81

File tree

46 files changed

+432
-79
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

46 files changed

+432
-79
lines changed

.travis.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -40,10 +40,10 @@ env:
4040
- RUN="integration" BOULDER_CONFIG_DIR="test/config-next"
4141
- RUN="unit"
4242
- RUN="unit-next" BOULDER_CONFIG_DIR="test/config-next"
43-
# godep-restore runs with a separate container because it needs to fetch
43+
# gomod-vendor runs with a separate container because it needs to fetch
4444
# packages from GitHub et. al., which is incompatible with the DNS server
4545
# override in the boulder container (used for service discovery).
46-
- RUN="godep-restore" CONTAINER="netaccess"
46+
- RUN="gomod-vendor" CONTAINER="netaccess"
4747
- RUN="coverage" CONTAINER="netaccess"
4848

4949
matrix:

CONTRIBUTING.md

Lines changed: 10 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -253,44 +253,22 @@ tag).
253253

254254
# Dependencies
255255

256-
We vendorize all our dependencies using `godep`. Vendorizing means we copy the contents of those dependencies into our own repo. This has a few advantages:
257-
- If the remote sites that host our various dependencies are unreachable, it is still possible to build Boulder solely from the contents of its repo.
258-
- The versions of our dependencies can't change out from underneath us.
256+
We use [go modules](https://github.com/golang/go/wiki/Modules) and vendor our
257+
dependencies. As of Go 1.12, this may require setting the GO111MODULE=on and
258+
GOFLAGS=-mod=vendor environment variables. Inside the Docker containers for
259+
Boulder tests, these variables are set for you, but if you ever work outside
260+
those containers you will want to set them yourself.
259261

260-
Note that this makes it possible to edit the local copy of our dependencies rather than the upstream copy. Occasionally we do this in great emergencies, but in general this is a bad idea because it means the next person to update that dependency will overwrite the changes.
261-
262-
Instead, it's better to contribute a patch upstream, then pull down changes. For dependencies that we expect to update semi-regularly, we create a fork in the letsencrypt organization, and vendorize that fork. For such forked dependencies, make changes by submitting a pull request to the letsencrypt fork. Once the pull request is reviewed and merged, (a) submit the changes as an upstream pull request, and (b) run `godep` to update to the latest version in the main Boulder. There are two advantages to this approach:
263-
- If upstream is slow to merge for any reason, we don't have to wait.
264-
- When we make changes, our first review is from other Boulder contributors rather than upstream. That way we make sure code meets our needs first before asking someone else to spend time on it.
262+
To add a dependency, add the import statement to your .go file, then run
263+
`go build` on it. This will automatically add the dependency to go.mod. Next,
264+
run `go mod vendor` to save a copy in the vendor folder.
265265

266266
When vendorizing dependencies, it's important to make sure tests pass on the version you are vendorizing. Currently we enforce this by requiring that pull requests containing a dependency update include a comment indicating that you ran the tests and that they succeeded, preferably with the command line you run them with.
267267

268268
## Updating Dependencies
269269

270-
All Go dependencies are vendored under the vendor directory, to [make dependency management easier](https://golang.org/cmd/go/#hdr-Vendor_Directories).
271-
272-
To update a dependencies:
273-
274-
```
275-
# Fetch godep
276-
go get -u github.com/tools/godep
277-
# Check out the currently vendorized version of each dependency.
278-
godep restore
279-
# Update to the latest version of a dependency. Alternately you can cd to the
280-
# directory under GOPATH and check out a specific revision. Here's an example
281-
# using cfssl:
282-
go get -u github.com/cloudflare/cfssl/...
283-
# Update the Godep config to the appropriate version.
284-
godep update github.com/cloudflare/cfssl/...
285-
# Save the dependencies
286-
godep save ./...
287-
git add Godeps vendor
288-
git commit
289-
```
290-
291-
NOTE: If you get "godep: no packages can be updated," there's a good chance you're trying to update a single package that belongs to a repo with other packages. For instance, `godep update golang.org/x/crypto/ocsp` will produce this error, because it's part of the `golang.org/x/crypto` repo, from which we also vendor other packages. Godep requires that all packages from the same repo be on the same version, so it can't update just one. See https://github.com/tools/godep/issues/164 for the issue dedicated to fixing it.
292-
293-
Certain dependencies we rely on themselves also vendor packages that we vendor. This generally isn't an issue unless the version that is vendored by our dependency uses a version with breaking changes from the version that we vendor. In this case either we need to switch to the same version or attempt to get the dependency to do the same.
270+
To upgrade a dependency, [see the Go
271+
docs](https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies).
294272

295273
# Go Version
296274

Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ $(OBJDIR):
3939
$(CMD_BINS): build_cmds
4040

4141
build_cmds: | $(OBJDIR)
42-
GOBIN=$(OBJDIR) go install $(GO_BUILD_FLAGS) ./...
42+
GOBIN=$(OBJDIR) GO111MODULE=on go install -mod=vendor $(GO_BUILD_FLAGS) ./...
4343
cp $(OBJDIR)/boulder-va $(OBJDIR)/boulder-remoteva
4444

4545
# Building an RPM requires `fpm` from https://github.com/jordansissel/fpm

docker-compose.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,8 @@ services:
77
FAKE_DNS: 10.77.77.77
88
PKCS11_PROXY_SOCKET: tcp://boulder-hsm:5657
99
BOULDER_CONFIG_DIR: test/config
10+
GO111MODULE: "on"
11+
GOFLAGS: "-mod=vendor"
1012
volumes:
1113
- .:/go/src/github.com/letsencrypt/boulder
1214
- ./.gocache:/root/.cache/go-build
@@ -74,6 +76,9 @@ services:
7476
driver: none
7577
netaccess:
7678
image: letsencrypt/boulder-tools-go${TRAVIS_GO_VERSION:-1.12}:2019-04-08
79+
environment:
80+
GO111MODULE: "on"
81+
GOFLAGS: "-mod=vendor"
7782
networks:
7883
- bluenet
7984
volumes:

go.mod

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
module github.com/letsencrypt/boulder
2+
3+
go 1.12
4+
5+
require (
6+
github.com/apoydence/onpar v0.0.0-20181125144932-f2f06780798d // indirect
7+
github.com/asaskevich/govalidator v0.0.0-20170903095215-73945b6115bf // indirect
8+
github.com/beeker1121/goque v0.0.0-20170321141813-4044bc29b280
9+
github.com/beorn7/perks v0.0.0-20160229213445-3ac7bf7a47d1 // indirect
10+
github.com/cloudflare/cfssl v0.0.0-20190409034051-768cd563887f
11+
github.com/go-gorp/gorp v2.0.0+incompatible // indirect
12+
github.com/go-sql-driver/mysql v0.0.0-20170715192408-3955978caca4
13+
github.com/golang/mock v1.2.0
14+
github.com/golang/protobuf v1.3.1
15+
github.com/golang/snappy v0.0.0-20170215233205-553a64147049 // indirect
16+
github.com/google/certificate-transparency-go v0.0.0-20181127102053-c25855a82c75
17+
github.com/grpc-ecosystem/go-grpc-prometheus v0.0.0-20170826090648-0dafe0d496ea
18+
github.com/jmhodges/clock v0.0.0-20160418191101-880ee4c33548
19+
github.com/jmoiron/sqlx v0.0.0-20180124204410-05cef0741ade // indirect
20+
github.com/kisielk/sqlstruct v0.0.0-20150923205031-648daed35d49 // indirect
21+
github.com/letsencrypt/challtestsrv v1.0.2
22+
github.com/letsencrypt/pkcs11key v1.0.0
23+
github.com/lib/pq v1.1.0 // indirect
24+
github.com/mattn/go-sqlite3 v1.10.0 // indirect
25+
github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
26+
github.com/miekg/dns v1.1.8
27+
github.com/miekg/pkcs11 v0.0.0-20180208123754-88ac7c418f89
28+
github.com/onsi/ginkgo v1.8.0 // indirect
29+
github.com/onsi/gomega v1.5.0 // indirect
30+
github.com/poy/onpar v0.0.0-20181125144932-f2f06780798d // indirect
31+
github.com/prometheus/client_golang v0.8.0
32+
github.com/prometheus/client_model v0.0.0-20150212101744-fa8ad6fec335
33+
github.com/prometheus/common v0.0.0-20161002210234-85637ea67b04 // indirect
34+
github.com/prometheus/procfs v0.0.0-20160411190841-abf152e5f3e9 // indirect
35+
github.com/stretchr/testify v1.3.0 // indirect
36+
github.com/syndtr/goleveldb v0.0.0-20180331014930-714f901b98fd // indirect
37+
github.com/titanous/rocacheck v0.0.0-20171023193734-afe73141d399
38+
github.com/weppos/publicsuffix-go v0.4.1-0.20190430132455-7c1d5dc5cdc2
39+
github.com/ziutek/mymysql v1.5.4 // indirect
40+
github.com/zmap/zcrypto v0.0.0-20180601141720-cf96f6a85166
41+
github.com/zmap/zlint v0.0.0-20190218154616-f38bd223a43c
42+
golang.org/x/crypto v0.0.0-20190411191339-88737f569e3a
43+
golang.org/x/net v0.0.0-20190415214537-1da14a5a36f2
44+
golang.org/x/sys v0.0.0-20190416152802-12500544f89f // indirect
45+
golang.org/x/text v0.3.0
46+
google.golang.org/appengine v1.4.0 // indirect
47+
google.golang.org/genproto v0.0.0-20190415143225-d1146b9035b9 // indirect
48+
google.golang.org/grpc v1.20.0
49+
gopkg.in/go-gorp/gorp.v2 v2.0.0-20180410155428-6032c66e0f5f
50+
gopkg.in/square/go-jose.v2 v2.1.4
51+
gopkg.in/yaml.v2 v2.2.2
52+
)

0 commit comments

Comments
 (0)