You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 9, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+4
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
1
# v0.5.1
2
2
3
+
IMPROVEMENTS:
4
+
5
+
* The `noverify` field in `Gopkg.toml` allows for the preservation of excess files under `vendor`. ([#2002](https://github.com/golang/dep/issue/2002))
6
+
3
7
BUG FIXES:
4
8
5
9
* Correctly handle certain cases where `dep ensure` removed projects from Gopkg.lock. ([#1945](https://github.com/golang/dep/issue/1945)).
Copy file name to clipboardExpand all lines: cmd/dep/testdata/harness_tests/ensure/noverify/vendororphans/initial/vendor/github.com/sdboyer/deptest/deptest.go
Copy file name to clipboardExpand all lines: docs/Gopkg.toml.md
+4-2
Original file line number
Diff line number
Diff line change
@@ -231,18 +231,20 @@ It is usually safe to set `non-go = true`, as well. However, as dep only has a c
231
231
232
232
## `noverify`
233
233
234
-
The `noverify` field is a list of [project roots](glossary.md#project-root) to exclude from [vendor verification](glossary.md#vendor-verification).
234
+
The `noverify` field is a list of paths, typically [project roots](glossary.md#project-root), to exclude from [vendor verification](glossary.md#vendor-verification).
235
235
236
236
Dep uses per-project hash digests, computed after pruning and recorded in [Gopkg.lock](Gopkg.lock.md#digest), to determine if the contents of `vendor/` are as expected. If the recorded digest and the hash of the corresponding tree in `vendor/` differ, that project is considered to be out of sync:
237
237
238
238
*`dep ensure` will regenerate it
239
239
*`dep check` will complain of a hash mismatch and exit 1
240
240
241
-
It is strongly preferable for almost all workflows that you leave `vendor/` unmodified, in whatever state dep puts it in. However, this isn't always an option. If you have no choice but to modify `vendor/` for a particular project, then add the project root for that project to `noverify`. This will have the following effects:
241
+
It is strongly recommended that you leave `vendor/` unmodified, in whatever state dep puts it in. However, this isn't always feasible. If you have no choice but to modify `vendor/` for a particular project, then add the project root for that project to `noverify`. This will have the following effects:
242
242
243
243
*`dep ensure` will ignore hash mismatches for the project, and only regenerate it in `vendor/` if absolutely necessary (prune options change, package list changes, version changes)
244
244
*`dep check` will continue to report hash mismatches (albeit with an annotation about `noverify`) for the project, but will no longer exit 1.
245
245
246
+
`noverify` can also be used to preserve certain excess paths that would otherwise be removed; for example, adding `WORKSPACE` to the `noverify` list would allow you to preserve `vendor/WORKSPACE`, which can help with some Bazel-based workflows.
Copy file name to clipboardExpand all lines: docs/ensure-mechanics.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Briefly, the four states are:
13
13
1. The [current project's](glossary.md#current-project) source code.
14
14
2. A [manifest](glossary.md#manifest) - a file describing the current project's dependency requirements. In dep, this is the [`Gopkg.toml`](Gopkg.toml.md) file.
15
15
3. A [lock](glossary.md#lock) - a file containing a transitively-complete, reproducible description of the dependency graph. In dep, this is the [`Gopkg.lock`](Gopkg.lock.md) file.
16
-
4. The source code of the dependences themselves. In dep's current design, this is the `vendor/` directory.
16
+
4. The source code of the dependencies themselves. In dep's current design, this is the `vendor/` directory.
17
17
18
18
We can visually represent these four states as follows:
19
19
@@ -156,7 +156,7 @@ Ordinarily, when the solver encounters a project name for which there's an entry
156
156
157
157
"Skips pulling the version from the lock" would imply that `dep ensure -update github.com/foo/bar` is equivalent to removing the `[[project]]` stanza for `github.com/foo/bar` from your `Gopkg.lock`, then running `dep ensure`. And indeed it is - however, that approach is not recommended, and subtle changes may be introduced in the future that complicate the equivalency.
158
158
159
-
If `-update` is passed with no arguments, then `ChangeAll` is set to `true`, resulting in the solver ignoring `Gopkg.lock` for all newly-encountered project names. This is equivalent to explicitly passing all of your dependences as arguments to `dep ensure -update`, as well as `rm Gopkg.lock && dep ensure`. Again, however, neither of these approaches are recommended, and future changes may introduce subtle differences.
159
+
If `-update` is passed with no arguments, then `ChangeAll` is set to `true`, resulting in the solver ignoring `Gopkg.lock` for all newly-encountered project names. This is equivalent to explicitly passing all of your dependencies as arguments to `dep ensure -update`, as well as `rm Gopkg.lock && dep ensure`. Again, however, neither of these approaches are recommended, and future changes may introduce subtle differences.
160
160
161
161
When a version hint from `Gopkg.lock` is not placed at the head of the version queue, it means that dep will explore the set of possible versions for a particular dependency. This exploration is performed according to a [fixed sort order](https://godoc.org/github.com/golang/dep/gps#SortForUpgrade), where newer versions are tried first, resulting in an update.
0 commit comments