Skip to content
This repository was archived by the owner on Sep 9, 2020. It is now read-only.

Commit 5bdd00b

Browse files
authored
Merge pull request #1293 from sudo-suhas/docs-ci-usage
update Best Practices FAQ for usage in CI
2 parents 2b53c10 + b92d0e7 commit 5bdd00b

File tree

1 file changed

+42
-18
lines changed

1 file changed

+42
-18
lines changed

docs/FAQ.md

+42-18
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,7 @@ Summarize the question and quote the reply, linking back to the original comment
3737
* [My dependers don't use `dep` yet. What should I do?](#my-dependers-dont-use-dep-yet-what-should-i-do)
3838
* [How do I configure a dependency that doesn't tag its releases?](#how-do-i-configure-a-dependency-that-doesnt-tag-its-releases)
3939
* [How do I use `dep` with Docker?](#how-do-i-use-dep-with-docker)
40+
* [How do I use `dep` in CI?](#how-do-i-use-dep-in-ci)
4041

4142
## Concepts
4243
### Does `dep` replace `go get`?
@@ -49,12 +50,12 @@ Here are some suggestions for when you could use `dep` or `go get`:
4950
> `go get`: I want to download the source code for a go project so that I can work on it myself, or to install a tool. This clones the repo under GOPATH for all to use.
5051
>
5152
> `dep ensure`: I have imported a new dependency in my code and want to download the dependency so I can start using it. My workflow is "add the import to the code, and then run dep ensure so that the manifest/lock/vendor are updated". This clones the repo under my project's vendor directory, and remembers the revision used so that everyone who works on my project is guaranteed to be using the same version of dependencies.
52-
>
53+
>
5354
> [@carolynvs in #376](https://github.com/golang/dep/issues/376#issuecomment-293964655)
5455
5556
> The long term vision is a sane, overall-consistent go tool. My general take is that `go get`
5657
> is for people consuming Go code, and dep-family commands are for people developing it.
57-
>
58+
>
5859
> [@sdboyer in #376](https://github.com/golang/dep/issues/376#issuecomment-294045873)
5960
6061
### Why is it `dep ensure` instead of `dep install`?
@@ -64,7 +65,7 @@ Here are some suggestions for when you could use `dep` or `go get`:
6465
> The idea of "ensure" is roughly, "ensure that all my local states - code tree, manifest, lock, and vendor - are in sync with each other." When arguments are passed, it becomes "ensure this argument is satisfied, along with synchronization between all my local states."
6566
>
6667
> We opted for this approach because we came to the conclusion that allowing the tool to perform partial work/exit in intermediate states ended up creating a tool that had more commands, had far more possible valid exit and input states, and was generally full of footguns. In this approach, the user has most of the same ultimate control, but exercises it differently (by modifying the code/manifest and re-running dep ensure).
67-
>
68+
>
6869
> [@sdboyer in #371](https://github.com/golang/dep/issues/371#issuecomment-293246832)
6970
7071
### What is a direct or transitive dependency?
@@ -77,7 +78,7 @@ Here are some suggestions for when you could use `dep` or `go get`:
7778
> The manifest describes user intent, and the lock describes computed outputs. There's flexibility in manifests that isn't present in locks..., as the "branch": "master" constraint will match whatever revision master HAPPENS to be at right now, whereas the lock is nailed down to a specific revision.
7879
>
7980
> This flexibility is important because it allows us to provide easy commands (e.g. `dep ensure -update`) that can manage an update process for you, within the constraints you specify, AND because it allows your project, when imported by someone else, to collaboratively specify the constraints for your own dependencies.
80-
>
81+
>
8182
> [@sdboyer in #281](https://github.com/golang/dep/issues/281#issuecomment-284118314)
8283
8384
## How do I constrain a transitive dependency's version?
@@ -113,7 +114,7 @@ No.
113114

114115
> Placing these files inside `vendor/` would concretely bind us to `vendor/` in the long term.
115116
> We prefer to treat the `vendor/` as an implementation detail.
116-
>
117+
>
117118
> [@sdboyer on go package management list](https://groups.google.com/d/msg/go-package-management/et1qFUjrkP4/LQFCHP4WBQAJ)
118119
119120
## How do I get dep to authenticate to a git repo?
@@ -243,7 +244,7 @@ Unable to update checked out version: fatal: reference is not a tree: 4dfc6a8a7e
243244
> The lock file represents a set of precise, typically immutable versions for the entire transitive closure of dependencies for a project. But "the project" can be, and is, decomposed into just a bunch of arguments to an algorithm. When those inputs change, the lock may need to change as well.
244245
>
245246
> Under most circumstances, if those arguments don't change, then the lock remains fine and correct. You've hit one one of the few cases where that guarantee doesn't apply. The fact that you ran dep ensure and it DID a solve is a product of some arguments changing; that solving failed because this particular commit had become stale is a separate problem.
246-
>
247+
>
247248
> [@sdboyer in #405](https://github.com/golang/dep/issues/405#issuecomment-295998489)
248249
249250
## Why is `dep` slow?
@@ -299,10 +300,10 @@ This is the only symbolic link support that `dep` really intends to provide. In
299300

300301
No.
301302
> dep simply doesn't allow relative imports. this is one of the few places where we restrict a case that the toolchain itself allows. we disallow them only because:
302-
>
303+
>
303304
> * the toolchain already frowns heavily on them<br>
304305
> * it's worse for our case, as we start venturing into [dot dot hell](http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames) territory when trying to prove that the import does not escape the tree of the project
305-
>
306+
>
306307
> [@sdboyer in #899](https://github.com/golang/dep/issues/899#issuecomment-317904001)
307308
308309
For a refresher on Go's recommended workspace organization, see the ["How To Write Go Code"](https://golang.org/doc/code.html) article in the Go docs. Organizing your code this way gives you a unique import path for every package.
@@ -315,7 +316,7 @@ found in `GOPATH`. `dep ensure` doesn't work with projects in `GOPATH`.
315316

316317
## Will `dep` let me use git submodules to store dependencies in `vendor`?
317318

318-
No, with just one tiny exception: `dep` preserves `/vendor/.git`, if it exists. This was added at [cockroachdb](https://github.com/cockroachdb/cockroach)'s request, who rely on it to keep `vendor` from bloating their primary repository.
319+
No, with just one tiny exception: `dep` preserves `/vendor/.git`, if it exists. This was added at [cockroachdb](https://github.com/cockroachdb/cockroach)'s request, who rely on it to keep `vendor` from bloating their primary repository.
319320

320321
The reasons why git submodules will not be a part of dep are best expressed as a pro/con list:
321322

@@ -427,19 +428,42 @@ This is especially useful for builds inside docker utilizing cache layers.
427428

428429
Sample dockerfile:
429430

430-
FROM golang:1.9 AS builder
431+
```Dockerfile
432+
FROM golang:1.9 AS builder
431433

432-
RUN curl -fsSL -o /usr/local/bin/dep https://github.com/golang/dep/releases/download/vX.X.X/dep-linux-amd64 && chmod +x /usr/local/bin/dep
434+
RUN curl -fsSL -o /usr/local/bin/dep https://github.com/golang/dep/releases/download/vX.X.X/dep-linux-amd64 && chmod +x /usr/local/bin/dep
433435

434-
RUN mkdir -p /go/src/github.com/***
435-
WORKDIR /go/src/github.com/***
436+
RUN mkdir -p /go/src/github.com/***
437+
WORKDIR /go/src/github.com/***
436438

437-
COPY Gopkg.toml Gopkg.lock ./
438-
# copies the Gopkg.toml and Gopkg.lock to WORKDIR
439+
COPY Gopkg.toml Gopkg.lock ./
440+
# copies the Gopkg.toml and Gopkg.lock to WORKDIR
439441

440-
RUN dep ensure -vendor-only
441-
# install the dependencies without checking for go code
442+
RUN dep ensure -vendor-only
443+
# install the dependencies without checking for go code
442444

443-
...
445+
...
446+
```
447+
448+
## How do I use `dep` in CI?
449+
450+
Since `dep` is expected to change until `v1.0.0` is released, it is recommended to rely on a released version.
451+
You can find the latest binary from the [releases](https://github.com/golang/dep/releases) page.
452+
453+
Sample configuration for Travis CI:
444454

455+
```yml
456+
# ...
445457

458+
env:
459+
- DEP_VERSION="X.X.X"
460+
461+
before_install:
462+
# Download the binary to bin folder in $GOPATH
463+
- curl -L -s https://github.com/golang/dep/releases/download/v${DEP_VERSION}/dep-linux-amd64 -o $GOPATH/bin/dep
464+
# Make the binary executable
465+
- chmod +x $GOPATH/bin/dep
466+
467+
install:
468+
- dep ensure
469+
```

0 commit comments

Comments
 (0)