mirror of https://github.com/pulumi/pulumi.git
d4f1cf5c87
### Motivation Pulumi plugin binaries can be downloaded by the CLI from multiple sources. By default, it's downloaded from Pulumi's GitHub releases or get.pulumi.com, but plugins can also specify their binary sources via the `PluginDownloadURL` schema option. They can point to custom GitHub, Gitlab, or HTTP locations. Enterprise customers ask for a way to isolate the CLI from downloads from random locations and to configure the CLI to go to their internal pre-approved artefact location instead. This way, Pulumi can run in "air-gapped" environments (which still have access to Cloud APIs, of course). Related issues: - https://github.com/pulumi/pulumi/issues/14459 - https://github.com/pulumi/pulumi/issues/16240 Currently, there is a basic mechanism to do so via the variable `pluginDownloadURLOverrides`, but it has two major limitations: - The variable value is set via a compile-time flag, so it requires a custom build of the CLI - The overrides are based on the plugin name, so the rules must be defined without access to the original URL, which makes it hard to provide universal rules and still distinguish between first-party, public third-party, or private in-house plugins - We ignore overrides for all plugins that have `PluginDownloadURL` set - Overrides can set a plugin replacement redirect only to HTTP(s) addresses ### Proposal This PR makes two sets of changes: 1. It allows passing overrides via the `PULUMI_PLUGIN_DOWNLOAD_URL_OVERRIDES` environment variable. The compile-time flag is still supported, but the env var takes priority. More configuration levers could be supported, but it not clear if we have good ones until [Support .pulumirc file for global config](https://github.com/pulumi/pulumi/issues/13484) is implemented. I don't expect users to want to set this via their stack configs, but I'm curious what others think. In any case, more sources can be added later. 2. The overrides now apply based on the original download URL, not just on plugin names. Actually, it's the base URL of a download source that is passed to the regexp matcher. Examples of possible options are: - `github://api.github.com/pulumi/pulumi-xyz` for a first-party plugin (note that we don't pass `get.pulumi.com` - `github://api.github.com/pulumiverse/pulumi-grafana` for a community plugin that sets `PluginDownloadURL` - `gitlab://gitlab-host/proj-name` for a community plugin hosted on Gitlab - `https://example.com/downloads/` for HTTP sources So, the override `^github://api.github.com/pulumi/pulumi-xyz=https://example.com/downloads/pulumi-xyz/` will override the single provider URL from our GitHub releases to the given HTTP location. On top of that, regular expressions may contain name groups to capture and use templated values. For example, `^github://api.github.com/(?P<org>[^/]+)/(?P<repo>[^/]+)=https://example.com/downloads/${org}/${repo}` captures any GitHub plugin and redirects it to its corresponding HTTP location. Group indices are also supported: the above override can also be written as `^github://api.github.com/(?P<org>[^/]+)/(?P<repo>[^/]+)=https://example.com/downloads/$1/$2`, with `$0` meaning the full match. The override URLs have the same semantics as `PluginDownloadURL`, so they can point to GitHub, Gitlab, HTTP, or anything we introduce in the future. ### Impact Technically, this is a breaking change, because name-based overrides will stop working. However, we are fairly certain that we have a single customer using the existing compile-time approach, and they indicated that they don't need the name-based overrides if they have URL-based overrides. I reviewed this PR with them and made sure they can migrate immediately after the change is released. Backwards compatibility is slightly tricky, because we'd need to keep name-based override _and_ not applying them to third-party plugins. But we can do it if necessary. Resolve #16240 |
||
|---|---|---|
| .. | ||
| env.go | ||