Skip to content

Commit

Permalink
Envtest Binary Version Manager Tool
Browse files Browse the repository at this point in the history
This introduces an envtest binary manager tool.
It can download binaries from GCS, list available versions,
print out help for switching between them, and remove old ones.

By default, it downloads binaries into an OS-specific cache directory,
as per the OS's conventions, but this can be overridden.
  • Loading branch information
DirectXMan12 committed Apr 23, 2021
1 parent 4aecab5 commit 80ec8f7
Show file tree
Hide file tree
Showing 15 changed files with 2,917 additions and 0 deletions.
108 changes: 108 additions & 0 deletions tools/setup-envtest/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
# Envtest Binaries Manager

This is a small tool that manages binaries for envtest. It can be used to
download new binaries, list currently installed and available ones, and
clean up versions.

To use it, just go-install it on 1.16+ (it's a separate, self-contained
module):

```shell
go install sigs.k8s.io/controller-runtime/tools/setup-envtest@latest
```

For full documentation, run it with the `--help` flag, but here are some
examples:

```shell
# download the latest envtest, and print out info about it
setup-envtest use

# download the latest 1.19 envtest, and print out the path
setup-envtest use -k '1.19.x!' -p path

# switch to the most recent 1.21 envtest on disk
source <(setup-envtest use -i -k '1.21.x' -p env)

# list all available local versions for darwin/amd64
setup-envtest list -i --os darwin --arch amd64

# remove all 1.16 versions from disk
setup-envtest cleanup -k '1.16.x'

# use the value from $KUBEBUILDER_ASSETS if set, otherwise follow the normal
# logic for 'use'
setup-envtest --use-env=always

# use the value from $KUBEBUILDER_ASSETS if set, otherwise use the latest
# installed version
setup-envtest use -i --use-env=always

# sideload a pre-downloaded tarball as Kubernetes 1.16.2 into our store
setup-envtest sideload -k '1.16.2' < downloaded-envtest.tar.gz
```

## Where does it put all those binaries?

By default, binaries are stored in an OS-specific cache directory, as per
the OS's conventions (see Go's `os.UserCacheDir`).

For example, on Linux this is `$XDG_CACHE_DIR`, or just `~/.config` if
that's unset.

There's an overall folder that holds all files, and inside that is
a folder for each version/platform pair. The exact directory structure is
not guarnateed, except that the leaf directory will contain the names
expected by envtest. You should always use `setup-envtest fetch` or
`setup-envtest switch` (generally with the `-p path` or `-p env` flags) to
get the directory that you should use.

## What if I don't want to talk to the internet?

There are a few options.

First, you'll probably want to set the `-i/--installed` flag. If you want
to avoid forgetting to set this flag, set the `ENVTEST_INSTALLED_ONLY`
env variable, which will switch that flag on by default.

Then, you have a few options for managing your binaries:

- If you don't *really* want to manage with this tool, or you want to
respect the $KUBEBUILDER_ASSETS variable if it's set to something
outside the store, use the `use --use-env=always -i` command.

`--use-env=always` makes the command unconditionally use the value of
KUBEBUILDER_ASSETS as long as it contains the required binaries, and
`-i` indicates that we only ever want to work with installed binaries
(no reaching out the the remote GCS storage).

As noted about, you can use `ENVTEST_INSTALLED_ONLY=true` to switch `-i`
on by default, and you can use `ENVTEST_USE_ENV=always` to switch
`--use-env=always` on by default.

- If you want to use this tool, but download your gziped tarballs
separately, you can use the `sideload` command. You'll need to use the
`-k/--version` flag to indicate which version you're sideloading.

After that, it'll be as if you'd installed the binaries with `use`.

- If you want to talk to some internal source, you can use the
`--remote-bucket` and `--remote-server` options. The former sets which
GCS bucket to download from, and the latter sets the host to talk to as
if it were a GCS endpoint. Theoretically, you could use the latter
version to run an internal "mirror" -- the tool expects

- `HOST/storage/v1/b/BUCKET/o` to return JSON like

```json
{"items": [
{"name": "kubebuilder-tools-X.Y.Z-os-arch.tar.gz", "md5Hash": "<base-64-encoded-md5-hash>"},
{"name": "kubebuilder-tools-X.Y.Z-os-arch.tar.gz", "md5Hash": "<base-64-encoded-md5-hash>"},
]}
```

- `HOST/storage/v1/b/BUCKET/o/TARBALL_NAME` to return JSON like
`{"name": "kubebuilder-tools-X.Y.Z-os-arch.tar.gz", "md5Hash": "<base-64-encoded-md5-hash>"}`

- `HOST/storage/v1/b/BUCKET/o/TARBALL_NAME?alt=media` to return the
actual file contents
Loading

0 comments on commit 80ec8f7

Please sign in to comment.