@xgent-ai/skills 0.1.0 → 0.4.0

package/skills/working-with-mise/references/dev-tools/backends/gitlab-html.md

@@ -0,0 +1,546 @@
+GitLab Backend
+
+GitLab Backend [​](#gitlab-backend)
+
+The `gitlab` backend installs release assets directly from GitLab repositories. It is ideal for tools that distribute pre-built binaries through GitLab releases.
+
+The code for this backend is in the mise repository at [`./src/backend/github.rs`](https://github.com/jdx/mise/blob/main/src/backend/github.rs).
+
+## Usage [​](#usage)
+
+GitLab release links have a display name as well as a download URL. `asset_pattern` matches the **display name**, which may differ from the filename. For example, GitLab Runner calls its Linux binary `binary: Linux amd64`.
+
+Add this to a project's `mise.toml` for Linux x64 or macOS arm64:
+
+toml
+
+```
+[tools."gitlab:gitlab-org/gitlab-runner"]
+version = "19.3.1"
+bin = "gitlab-runner"
+
+[tools."gitlab:gitlab-org/gitlab-runner".platforms]
+linux-x64 = { asset_pattern = "binary: Linux amd64" }
+macos-arm64 = { asset_pattern = "binary: macOS arm64" }
+```
+
+sh
+
+```
+mise install
+mise exec -- gitlab-runner --version
+```
+
+This installs the executable; it does not register a runner or create a service. For another platform or release, inspect the project's release links and adjust the pattern. Version listing uses releases with attached links, not arbitrary Git tags or GitLab's generated source archives.
+
+## Authentication [​](#authentication)
+
+For private repositories or higher API limits, mise supports several GitLab token sources.
+
+### Token priority [​](#token-priority)
+
+mise checks these sources in order and uses the first token found:
+
+1. `MISE_GITLAB_ENTERPRISE_TOKEN` (for non- `gitlab.com` hosts)
+2. `MISE_GITLAB_TOKEN`
+3. `GITLAB_TOKEN`
+4. `credential_command` (if set)
+5. `gitlab_tokens.toml` (per host)
+6. glab CLI config ( `config.yml`, if enabled)
+7. `git credential fill` (if `gitlab.use_git_credentials=true`)
+
+### Environment variables [​](#environment-variables)
+
+sh
+
+```
+export MISE_GITLAB_TOKEN="glpat-xxxxxxxx"
+```
+
+For self-hosted GitLab instances:
+
+sh
+
+```
+export MISE_GITLAB_ENTERPRISE_TOKEN="glpat-yyyyyyyy"
+```
+
+### Token file (`gitlab_tokens.toml`) [​](#token-file-gitlab-tokens-toml)
+
+toml
+
+```
+# ~/.config/mise/gitlab_tokens.toml
+[tokens."gitlab.com"]
+token = "glpat-xxxxxxxx"
+
+[tokens."gitlab.mycompany.com"]
+token = "glpat-yyyyyyyy"
+```
+
+### `credential_command` [​](#credential-command)
+
+Set this in your **global** `~/.config/mise/config.toml`. Project configuration cannot set `credential_command`. The command must print only the token to stdout:
+
+toml
+
+```
+[settings.gitlab]
+credential_command = "op read 'op://Private/GitLab Token/credential'"
+```
+
+mise executes this command with the configured default inline shell. The target hostname is available as `MISE_CREDENTIAL_HOST`, and the provider name (`gitlab`) is available as `MISE_CREDENTIAL_PROVIDER`. For compatibility, recognized sh-compatible shells (`ash`, `bash`, `dash`, `ksh`, `sh`, and `zsh`) also receive the hostname as `$1`/`${1}`.
+
+Planned deprecation
+
+The legacy `$1`/`${1}` hostname argument is deprecated. Use `MISE_CREDENTIAL_HOST` instead. mise will start warning in `2026.11.0`, and `$1` compatibility will be removed in `2027.11.0`.
+
+### glab CLI integration [​](#glab-cli-integration)
+
+mise can read tokens from [glab](https://gitlab.com/gitlab-org/cli) config as a fallback. It checks:
+
+1. `$GLAB_CONFIG_DIR/config.yml`
+2. `~/.config/glab-cli/config.yml` — glab's legacy location on every platform, which glab still prefers when the file exists
+3. `$XDG_CONFIG_HOME/glab-cli/config.yml`
+4. `~/Library/Application Support/glab-cli/config.yml` (macOS)
+5. `%LOCALAPPDATA%\glab-cli\config.yml` (Windows — glab resolves `XDG_CONFIG_HOME` to `%LOCALAPPDATA%` there, unlike `gh`, which uses `%APPDATA%`)
+
+Disable this fallback with:
+
+toml
+
+```
+[settings.gitlab]
+glab_cli_tokens = false
+```
+
+### `git credential fill` fallback [​](#git-credential-fill-fallback)
+
+As a last resort, mise can query git credential helpers:
+
+toml
+
+```
+[settings.gitlab]
+use_git_credentials = true
+```
+
+This uses `git credential fill` and supports credentials stored by helpers such as macOS Keychain.
+
+### Debugging token resolution [​](#debugging-token-resolution)
+
+Use `mise token gitlab` to see which token mise would use for a given host:
+
+sh
+
+```
+mise token gitlab
+mise token gitlab gitlab.mycompany.com
+```
+
+Token diagnostics are masked by default. `--unmask` prints the actual credential; use it only when you need the secret itself, and keep it out of shared logs.
+
+## Tool Options [​](#tool-options)
+
+Platform-specific download URLs support the same version templates as the [GitHub backend](https://mise.jdx.dev/dev-tools/backends/github.html#platform-specific-urls).
+
+The following [tool-options](https://mise.jdx.dev/dev-tools/#tool-options) are available for the `gitlab` backend—these go in `[tools]` in `mise.toml`.
+
+### Asset Autodetection [​](#asset-autodetection)
+
+When no `asset_pattern` is specified, mise automatically selects the best asset for your platform. It scores assets on:
+
+- **OS compatibility** (linux, macos, windows)
+- **Architecture compatibility** (x64, arm64, x86, arm)
+- **Libc variant** (gnu or musl for Linux, msvc for Windows)
+- **Archive format preference** (tar.gz, zip, etc.)
+- **Build type** (avoids debug/test builds)
+
+For most tools, you can install without specifying a pattern:
+
+sh
+
+```
+mise install gitlab:user/repo
+```
+
+TIP
+
+The autodetection logic is implemented in [`src/backend/asset_matcher.rs`](https://github.com/jdx/mise/blob/main/src/backend/asset_matcher.rs), which is shared by the GitHub, GitLab, and Forgejo backends.
+
+### `asset_pattern` [​](#asset-pattern)
+
+Specifies a glob matched against the release link's display name. This is useful when there are multiple assets for your OS/arch combination or when you need to override autodetection.
+
+toml
+
+```
+[tools."gitlab:gitlab-org/gitlab-runner"]
+version = "latest"
+bin = "gitlab-runner"
+asset_pattern = "binary: Linux amd64"
+```
+
+### `matching` [​](#matching)
+
+Narrows asset selection to names containing the given substring, **while keeping platform autodetection**. Unlike [`asset_pattern`](https://mise.jdx.dev/dev-tools/backends/gitlab.html#asset-pattern) (which replaces autodetection entirely), `matching` only refines the candidate set — autodetection still chooses the correct OS/arch from the narrowed list, so a single config stays portable across platforms.
+
+This is the option to reach for when a repository ships **multiple binaries as separate per-platform assets** and autodetection can't tell which one you want.
+
+toml
+
+```
+[tools]
+# When a release ships several binaries per platform (e.g. `mytool-cli` and
+# `mytool-server`), matching picks one on every OS/arch without hardcoding a
+# platform-specific asset_pattern.
+"gitlab:owner/repo" = { version = "latest", matching = "mytool-cli" }
+```
+
+Tool options can also be passed inline on the command line using `[key=value]` syntax:
+
+sh
+
+```
+mise use "gitlab:owner/repo[matching=mytool-cli]"
+```
+
+`matching` is a case-sensitive substring test, so a value that is also a substring of another asset's name (e.g. `matching = "tool"` when both `tool-*` and `tool-extras-*` are published) won't uniquely select your binary. Use [`matching_regex`](https://mise.jdx.dev/dev-tools/backends/gitlab.html#matching-regex) with an anchor when you need a precise match.
+
+If [`asset_pattern`](https://mise.jdx.dev/dev-tools/backends/gitlab.html#asset-pattern) is also set, it takes precedence and `matching`/`matching_regex` are ignored — `asset_pattern` replaces autodetection entirely, so there is no candidate set left for them to narrow. They are ignored silently: when `asset_pattern` is set, a `matching_regex` is never consulted and an invalid one is not reported, since mise does not error on a superseded option.
+
+### `matching_regex` [​](#matching-regex)
+
+Like [`matching`](#matching), but the asset name must match the given regular expression. Use this when a substring isn't selective enough. The match is case-sensitive; use an inline `(?i)` flag for case-insensitive matching.
+
+toml
+
+```
+[tools]
+"gitlab:owner/repo" = { version = "latest", matching_regex = "^mytool-cli-" }
+```
+
+If both `matching` and `matching_regex` are set, an asset must satisfy **both** (logical AND) to remain a candidate.
+
+WARNING
+
+`matching`/`matching_regex` are **not** part of the install path — it is keyed by the tool name (`owner/repo`, or a `tool_alias`) and version. To install two binaries from the same release, give each its own [`tool_alias`](https://mise.jdx.dev/dev-tools/backends/github.html#multiple-assets-from-the-same-release) so they get distinct install directories; reusing the same `gitlab:owner/repo` string with different `matching` values resolves to the same directory and the second install overwrites the first.
+
+### `version_prefix` [​](#version-prefix)
+
+Specifies a custom version prefix for release tags. By default, mise handles the common `v` prefix (e.g., `v1.0.0`), but some repositories use different prefixes like `release-`, `version-`, or no prefix at all.
+
+When `version_prefix` is configured, mise will:
+
+- Filter available versions with the prefix and strip it
+- Add the prefix when searching for releases
+- Try both prefixed and non-prefixed versions during installation
+
+toml
+
+```
+[tools]
+"gitlab:user/repo" = { version = "latest", version_prefix = "release-" }
+```
+
+**Examples:**
+
+- With `version_prefix = "release-"`:
+  - User specifies `1.0.0` → mise searches for `release-1.0.0` tag
+  - Available versions show as `1.0.0` (prefix stripped)
+- With `version_prefix = ""` (empty string):
+  - User specifies `1.0.0` → mise searches for `1.0.0` tag (no prefix)
+  - Useful for repositories that don't use any prefix
+
+### Platform-specific Asset Patterns [​](#platform-specific-asset-patterns)
+
+To use different asset patterns per platform:
+
+toml
+
+```
+[tools."gitlab:gitlab-org/gitlab-runner"]
+version = "latest"
+bin = "gitlab-runner"
+
+[tools."gitlab:gitlab-org/gitlab-runner".platforms]
+linux-x64 = { asset_pattern = "binary: Linux amd64" }
+macos-arm64 = { asset_pattern = "binary: macOS arm64" }
+```
+
+### `checksum` [​](#checksum)
+
+Set an expected digest for a **specific version and artifact**. Replace the placeholder below with the full SHA-256 digest obtained from a trusted source:
+
+toml
+
+```
+[tools."gitlab:owner/repo"]
+version = "1.0.0"
+asset_pattern = "tool-1.0.0-x64.tar.gz"
+checksum = "sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST"
+```
+
+*Instead of specifying the checksum here, you can use [mise.lock](https://mise.jdx.dev/dev-tools/mise-lock.html) to manage checksums.*
+
+### Platform-specific Checksums [​](#platform-specific-checksums)
+
+Each platform needs its own digest. These values are placeholders; fill them from the publisher before installing, or generate [mise.lock](https://mise.jdx.dev/dev-tools/mise-lock.html).
+
+toml
+
+```
+[tools."gitlab:gitlab-org/gitlab-runner"]
+version = "19.3.1"
+bin = "gitlab-runner"
+
+[tools."gitlab:gitlab-org/gitlab-runner".platforms]
+linux-x64 = {
+  asset_pattern = "binary: Linux amd64",
+  checksum = "sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST",
+}
+macos-arm64 = {
+  asset_pattern = "binary: macOS arm64",
+  checksum = "sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST",
+}
+```
+
+### `size` [​](#size)
+
+Optionally check the expected byte count. The number below is illustrative; use the selected artifact's actual size and pin its version. A size check does not authenticate the publisher or replace a checksum:
+
+toml
+
+```
+[tools]
+"gitlab:owner/repo" = { version = "1.0.0", size = "12345678" }
+```
+
+### Platform-specific Size [​](#platform-specific-size)
+
+Use each artifact's actual byte count; the following numbers illustrate the syntax:
+
+toml
+
+```
+[tools."gitlab:gitlab-org/gitlab-runner"]
+version = "19.3.1"
+bin = "gitlab-runner"
+
+[tools."gitlab:gitlab-org/gitlab-runner".platforms]
+linux-x64 = { asset_pattern = "binary: Linux amd64", size = "12345678" }
+macos-arm64 = { asset_pattern = "binary: macOS arm64", size = "9876543" }
+```
+
+### `strip_components` [​](#strip-components)
+
+Number of directory components to strip when extracting archives:
+
+toml
+
+```
+[tools]
+"gitlab:owner/repo" = { version = "1.0.0", strip_components = 1 }
+```
+
+INFO
+
+When both `strip_components` and `bin_path` are unset, mise automatically applies `strip_components = 1` when the extracted archive contains exactly one directory at the root level and no files. This is common with tools like ripgrep that package their binaries in a versioned directory (e.g., `ripgrep-14.1.0-x86_64-unknown-linux-musl/rg`). Auto-detection places the binary directly in the install path where mise expects it.
+
+### `bin` [​](#bin)
+
+Rename the downloaded binary to a specific name. This is useful for single-binary downloads with platform-specific names:
+
+toml
+
+```
+[tools."gitlab:myorg/mytool"]
+version = "1.0.0"
+asset_pattern = "mytool-linux-x86_64"
+bin = "mytool"  # Rename from mytool-linux-x86_64 to mytool
+```
+
+INFO
+
+When downloading single binaries (not archives), mise automatically removes OS/arch suffixes from the filename. For example, `mytool-linux-x86_64` becomes `mytool`. Use the `bin` option only when you need a specific custom name.
+
+### `rename_exe` [​](#rename-exe)
+
+Rename the executable after extracting it from an archive. This is useful when the archive contains a binary with a platform-specific name:
+
+toml
+
+```
+[tools."gitlab:myorg/mytool"]
+version = "latest"
+asset_pattern = "mytool_linux.zip"
+rename_exe = "mytool"  # Rename the extracted binary to mytool
+```
+
+TIP
+
+Use `rename_exe` for archives whose binary has a different name than you want. Use `bin` for single-binary downloads (non-archives).
+
+### `no_app` [​](#no-app)
+
+Skip macOS .app bundle assets during autodetection and prefer standalone CLI binaries. This is useful when a repository provides both a macOS .app bundle (often an Xcode extension or GUI application) and a standalone command-line tool:
+
+toml
+
+```
+[tools."gitlab:myorg/mytool"]
+version = "latest"
+no_app = true
+```
+
+When `no_app = true`:
+
+- Assets containing `.app.` (e.g., `Tool.app.zip`, `Tool.for.Xcode.app.zip`) are penalized during autodetection
+- Standalone archives are preferred
+- The option is mainly useful for macOS asset selection; non-macOS `.app.` assets are already penalized by platform matching
+- Only autodetection is affected; explicit `asset_pattern` values are used as-is
+
+### `bin_path` [​](#bin-path)
+
+Paths are relative to the install directory **after** `strip_components` is applied. Setting `bin_path` disables automatic root stripping. For an archive shaped like `tool-VERSION/bin/tool`, either retain the outer directory and use `bin_path = "tool-/bin"`, or set both `strip_components = 1` and `bin_path = "bin"`.
+
+Specify the directory containing binaries within the extracted archive, or where to place the downloaded file. This supports Tera templating with `{{ version }}` and the `{{ os() }}` / `{{ arch() }}` functions:
+
+toml
+
+```
+[tools."gitlab:owner/repo"]
+version = "1.0.0"
+strip_components = 1
+bin_path = "bin" # for an archive shaped like tool-VERSION/bin/tool
+```
+
+Both take keyword arguments that remap the value mise would emit (`linux`, `macos`, `windows` for `os()`; `x64`, `arm64` for `arch()`), for when upstream names the directory differently:
+
+toml
+
+```
+[tools."gitlab:owner/repo"]
+version = "latest"
+# expands to tool-1.0.0-linux-x86_64/bin
+strip_components = 0
+bin_path = 'tool-{{ version }}-{{ os() }}-{{ arch(x64="x86_64", arm64="aarch64") }}/bin'
+```
+
+TIP
+
+Use a single-quoted TOML string when the template contains double quotes, as above.
+
+There are no bare `{{ os }}` / `{{ arch }}` variables, and no `{{ x86_64_arch }}`-style aliases — `{{ arch(x64="x86_64", arm64="aarch64") }}` is how you get those names.
+
+**Binary path lookup order:**
+
+1. If `bin_path` is specified, use that directory
+2. If `bin_path` is not set, look for a `bin/` directory in the install path
+3. If the install path root contains an executable file, use the install path root
+4. If no `bin/` directory exists, search subdirectories for `bin/` directories
+5. If no `bin/` directories are found, search immediate subdirectories for executable files. If an executable is found directly within a subdirectory, that subdirectory is treated as a binary path.
+6. If no executables are found, use the root of the extracted directory
+
+### `filter_bins` [​](#filter-bins)
+
+List of binaries to symlink into a filtered `.mise-bins` directory. This is useful when the tool comes with extra binaries that you do not want to expose on PATH.
+
+toml
+
+```
+[tools]
+"gitlab:myorg/mytool" = { version = "1.0.0", filter_bins = "mybin" }
+"gitlab:myorg/other-tool" = { version = "1.0.0", filter_bins = ["mybin", "helper"] }
+```
+
+When enabled:
+
+- A `.mise-bins` subdirectory is created with symlinks only to the specified binaries
+- Other binaries are not exposed on PATH
+
+### `api_url` [​](#api-url)
+
+For self-hosted GitLab instances, specify the API URL. mise uses this URL for release listing and release asset lookup, and may also use it to download assets when browser download URLs are not reachable or the instance is custom or private:
+
+toml
+
+```
+[tools]
+"gitlab:myorg/mytool" = { version = "latest", api_url = "https://gitlab.mycompany.com/api/v4" }
+```
+
+## Private GitLab repositories [​](#private-gitlab-repositories)
+
+To install a tool from a private repository on `gitlab.com`, set the `MISE_GITLAB_TOKEN` environment variable for authentication:
+
+sh
+
+```
+export MISE_GITLAB_TOKEN="your-token"
+```
+
+## Self-hosted GitLab [​](#self-hosted-gitlab)
+
+For a self-hosted GitLab instance, set the `api_url` tool option and, optionally, the `MISE_GITLAB_ENTERPRISE_TOKEN` environment variable for authentication:
+
+sh
+
+```
+export MISE_GITLAB_ENTERPRISE_TOKEN="your-token"
+```
+
+## Supported GitLab Syntax [​](#supported-gitlab-syntax)
+
+- **GitLab shorthand for latest release version:** `gitlab:gitlab-org/gitlab-runner`
+- **GitLab shorthand for specific release version:** `gitlab:gitlab-org/gitlab-runner@16.8.0`
+
+## Settings [​](#settings)
+
+### `gitlab.credential_command`[](#gitlab.credential_command)
+
+- Type: `string`
+- Env: `MISE_GITLAB_CREDENTIAL_COMMAND`
+- Default:
+
+When set, mise executes this command via `sh -c` and reads the token from stdout. The hostname is exposed as `MISE_CREDENTIAL_HOST`, making the command host-aware for self-managed GitLab environments. This replaces the `git credential fill` fallback and does not require `gitlab.use_git_credentials` to be enabled.
+
+The command should print a single token to stdout. Trailing whitespace is trimmed.
+
+Example: `op read "op://Private/GitLab Token/credential"`
+
+### `gitlab.glab_cli_tokens`[](#gitlab.glab_cli_tokens)
+
+- Type: `boolean`
+- Env: `MISE_GITLAB_GLAB_CLI_TOKENS`
+- Default: `true`
+
+When enabled, mise will read tokens from the glab CLI config file (`~/.config/glab-cli/config.yml` or `$GLAB_CONFIG_DIR/config.yml`) as a fallback when no `GITLAB_TOKEN` or `MISE_GITLAB_TOKEN` environment variable is set.
+
+Set to `false` to disable this behavior.
+
+### `gitlab.use_git_credentials`[](#gitlab.use_git_credentials)
+
+- Type: `boolean`
+- Env: `MISE_GITLAB_USE_GIT_CREDENTIALS`
+- Default: `false`
+
+When enabled, mise will run `git credential fill` to obtain GitLab tokens using the credential helpers configured in your `.gitconfig`.
+
+This covers tokens stored in system keyrings (macOS Keychain, Windows Credential Manager), and any other git credential helper.
+
+Used as a last resort — after environment variables, `gitlab_tokens.toml`, and glab CLI tokens are checked. Results are cached per host for the duration of the session.
+
+Set to `true` to enable this behavior.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/backends/gitlab.md)
+
+Last updated:
+
+Pager
+
+[Previous pagegithub](https://mise.jdx.dev/dev-tools/backends/github.html)
+
+[Next pagego](https://mise.jdx.dev/dev-tools/backends/go.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)

package/skills/working-with-mise/references/dev-tools/backends/go-html.md

@@ -0,0 +1,115 @@
+Go Backend
+
+Go Backend [​](#go-backend)
+
+The `go` backend builds Go command-line packages with `go install`. Use the import path of the executable package, which may include `/cmd/TOOL` or a major version suffix such as `/v4`. Libraries belong in your application's `go.mod`.
+
+The code for this is inside the mise repository at [`./src/backend/go.rs`](https://github.com/jdx/mise/blob/main/src/backend/go.rs).
+
+## Dependencies [​](#dependencies)
+
+Install Go and the tool in the current project. The configured Go installation is available while mise builds the dependent tool:
+
+sh
+
+```
+mise use go@1.26 go:github.com/DarthSim/hivemind
+mise exec -- hivemind --help
+```
+
+This records both tools in `mise.toml`; add `-g` for global configuration. Source builds may also need Git, a C compiler, or native libraries, depending on the package and whether it uses cgo.
+
+## Usage [​](#usage)
+
+List available versions with `mise ls-remote go:github.com/DarthSim/hivemind`. To select one, run `mise use go:github.com/DarthSim/hivemind@VERSION`, replacing `VERSION` with a listed release. mise writes the resulting executable into its own installation directory instead of your ordinary `GOBIN`.
+
+### Version discovery and release dates [​](#version-discovery-and-release-dates)
+
+For `latest`, mise first queries the module proxy or `go list` directly for the latest stable release. This avoids listing every version and fetching a release date for each one, which can time out on modules with many tags.
+
+Commands such as `mise ls-remote` and version requests such as `@1` still use the full version list. To keep these lookups fast, mise fetches release dates for only the newest 100 versions through a module proxy, or the newest 10 through `go list`. All versions remain in the list; versions outside these limits have no release date.
+
+A version with no release date is still checked against [`minimum_release_age`](https://mise.jdx.dev/configuration/settings.html#minimum_release_age): before mise settles on one, it reads that single version's date and moves further back while the answer is newer than the cutoff. A cutoff deep enough to reach past the dated versions therefore costs one query per version it skips, which can make the first resolution of a module with many releases noticeably slower through `go list`. The direct `latest` query includes a release date, and if that release is too recent mise falls back to the full list and dates candidates from there.
+
+Unreachable sources
+
+If reading a version's date fails outright — an unreachable proxy, a VCS host that times out — mise warns and allows that version rather than failing the install. A version can therefore still slip past the cutoff on a bad network, and the warning is what tells you it happened.
+
+### Private modules [​](#private-modules)
+
+Private modules use Go's normal VCS authentication. Export `GOPRIVATE`, or define it in mise's `[env]` configuration, so mise delegates version discovery to Go instead of querying the public module proxy itself. Values set only with `go env -w` are not read by mise when choosing the discovery path:
+
+toml
+
+```
+[env]
+GOPRIVATE = "github.com/acme/*"
+```
+
+Go uses `GOPRIVATE` as the default for both `GONOPROXY` and `GONOSUMDB`. If you configure those variables separately, set each one according to the proxy and checksum-database privacy you need.
+
+### Pinned versions [​](#pinned-versions)
+
+You can also pin a specific Go module version, including an unreleased pseudo-version:
+
+toml
+
+```
+[tools]
+"go:github.com/grafana/oats" = "v0.7.1-0.20260703092802-96201f1b8136"
+```
+
+If you need to resolve an unreleased revision directly from VCS instead of the module proxy, combine the pinned version with [`install_env`](https://mise.jdx.dev/dev-tools/backends/go.html#install-env):
+
+toml
+
+```
+[tools]
+"go:github.com/grafana/oats" = { version = "v0.7.1-0.20260703092802-96201f1b8136", install_env = { GOPROXY = "direct", GONOSUMDB = "github.com/grafana/oats" } }
+```
+
+## Tool Options [​](#tool-options)
+
+The following [tool-options](https://mise.jdx.dev/dev-tools/#tool-options) are available for the `go` backend—these go in `[tools]` in `mise.toml`.
+
+### `install_env` [​](#install-env)
+
+Set environment variables for the `go install` command. mise still sets `GOBIN` to the tool install directory after applying `install_env`. Put `GOPRIVATE` in `[env]` as shown above when it must also affect version discovery.
+
+toml
+
+```
+[tools]
+"go:github.com/acme/my-tool" = { version = "latest", install_env = { GOPRIVATE = "github.com/acme/*" } }
+```
+
+### `tags` [​](#tags)
+
+Specify Go build tags (passed as `go install -tags`):
+
+toml
+
+```
+[tools]
+"go:github.com/golang-migrate/migrate/v4/cmd/migrate" = { version = "latest", tags = "postgres" }
+# equivalent array form:
+# "go:github.com/golang-migrate/migrate/v4/cmd/migrate" = { version = "latest", tags = ["postgres", "mysql"] }
+```
+
+## Troubleshooting [​](#troubleshooting)
+
+- **Package is not a main package:** use the executable's import path, not the repository root or a library package.
+- **Private module lookup fails:** check exported `GOPRIVATE` and your Go/Git credentials; mise's GitHub token is not a substitute for VCS authentication.
+- **Go version or compiler error:** use a toolchain supported by the package and install any required native build dependencies.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/backends/go.md)
+
+Last updated:
+
+Pager
+
+[Previous pagegitlab](https://mise.jdx.dev/dev-tools/backends/gitlab.html)
+
+[Next pagehttp](https://mise.jdx.dev/dev-tools/backends/http.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)