"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "CONTRIBUTING.md" between
boulder-release-2020-06-23.tar.gz and boulder-release-2020-06-29.tar.gz

About: Boulder is an ACME-based Certificate Authority (CA) used by Let’s Encrypt (written in Go).

CONTRIBUTING.md  (boulder-release-2020-06-23):CONTRIBUTING.md  (boulder-release-2020-06-29)
skipping to change at line 324 skipping to change at line 324
# Dependencies # Dependencies
We use [go modules](https://github.com/golang/go/wiki/Modules) and vendor our We use [go modules](https://github.com/golang/go/wiki/Modules) and vendor our
dependencies. As of Go 1.12, this may require setting the GO111MODULE=on and dependencies. As of Go 1.12, this may require setting the GO111MODULE=on and
GOFLAGS=-mod=vendor environment variables. Inside the Docker containers for GOFLAGS=-mod=vendor environment variables. Inside the Docker containers for
Boulder tests, these variables are set for you, but if you ever work outside Boulder tests, these variables are set for you, but if you ever work outside
those containers you will want to set them yourself. those containers you will want to set them yourself.
To add a dependency, add the import statement to your .go file, then run To add a dependency, add the import statement to your .go file, then run
`go build` on it. This will automatically add the dependency to go.mod. Next, `go build` on it. This will automatically add the dependency to go.mod. Next,
run `go mod vendor` to save a copy in the vendor folder. run `go mod vendor && git add vendor/` to save a copy in the vendor folder.
When vendorizing dependencies, it's important to make sure tests pass on the 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 version you are vendorizing. Currently we enforce this by requiring that pull
requests containing a dependency update include a comment indicating that you requests containing a dependency update to any version other than a tagged
ran the tests and that they succeeded, preferably with the command line you release include a comment indicating that you ran the tests and that they
run them with. succeeded, preferably with the command line you run them with. Note that you
may have to get a separate checkout of the dependency (using `go get` outside
of the boulder repository) in order to run its tests, as some vendored
modules do not bring their tests with them.
## Updating Dependencies ## Updating Dependencies
To upgrade a dependency, [see the Go To upgrade a dependency, [see the Go
docs](https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dep endencies). docs](https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dep endencies).
Typically you want `go get <dependency>` rather than `go get -u Typically you want `go get <dependency>` rather than `go get -u
<dependency>`, which can introduce a lot of unexpected updates. After running <dependency>`, which can introduce a lot of unexpected updates. After running
`go get`, make sure to run `go mod vendor` to update the vendor directory. If `go get`, make sure to run `go mod vendor && git add vendor/` to update the
you forget, Travis tests will catch this. vendor directory. If you forget, Travis tests will catch this.
If you are updating a dependency to a version which is not a tagged release,
see the note above about how to run all of a dependency's tests and note that
you have done so in the PR.
Note that updating dependencies can introduce new, transitive dependencies. In Note that updating dependencies can introduce new, transitive dependencies. In
general we try to keep our dependencies as narrow as possible in order to general we try to keep our dependencies as narrow as possible in order to
minimize the number of people and organizations whose code we need to trust. minimize the number of people and organizations whose code we need to trust.
As a rule of thumb: If an update introduces new packages or modules that are As a rule of thumb: If an update introduces new packages or modules that are
inside a repository where we already depend on other packages or modules, it's inside a repository where we already depend on other packages or modules, it's
not a big deal. If it introduces a new dependency in a different repository, not a big deal. If it introduces a new dependency in a different repository,
please try to figure out where that dependency came from and why (for instance: please try to figure out where that dependency came from and why (for instance:
"package X, which we depend on, started supporting XML config files, so now we "package X, which we depend on, started supporting XML config files, so now we
depend on an XML parser") and include that in the PR description. When there are depend on an XML parser") and include that in the PR description. When there are
 End of changes. 3 change blocks. 
6 lines changed or deleted 13 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)