The fact that services such as gopkg.in always redirect the go get tool to the latest available major version for a given version selector is, technically speaking, a show-stopper for engineering teams that endeavor to set up a development pipeline that guarantees repeatable builds. The typical CI pipeline will always pull both compile and test dependencies via a command such as go get -t -u ... prior to building the final output artifact. As a result, even if your code has not changed between builds, your service or application binary may be different because of changes in the dependencies that get pulled in.
However, what if I told you that there is actually a way to retain the benefits of lazy package resolution and at the same time have the flexibility to pin down package versions for each build? The mechanism that will assist us in this matter is called vendoring.
As we will see in the following sections, there are a few different approaches to creating dependency snapshots:
- Fork the repository that contains each imported dependency and update the import statements in the code base to point to the forked resources.
- Create a manifest that includes the current (that is, at the time a snapshot is made) commit identifiers (for example, Git SHAs) for each imported package and its transitive dependencies. The manifest, a small, human-readable YAML- or JSON-based file is generally committed to the VCS and used to fetch the appropriate versions of each dependency prior to invoking the compiler.
- Cache the imported dependencies locally (typically in a folder called vendor) and commit them together with the project files to the VCS. Contrary to the preceding approaches, local caching enables us to check out our project and immediately compile it without having to fetch any dependencies first.
Before we dive a bit deeper into each one of these approaches, let's take a few minutes to discuss the pros and cons of dependency vendoring.