New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to override PluginDownloadURL
if it is explicitly set on a plugin
#16058
Labels
area/plugins
Plugin acquisition and resolution
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs
kind/enhancement
Improvements or new features
resolution/fixed
This issue was fixed
Milestone
Comments
zbuchheit
added
kind/enhancement
Improvements or new features
needs-triage
Needs attention from the triage team
customer/feedback
Feedback from customers
area/plugins
Plugin acquisition and resolution
customer/lighthouse
Lighthouse customer bugs
labels
Apr 25, 2024
6 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
May 13, 2024
… the package (#16186) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Overriding plugin download URLs with compilation flags was originally added in #8798. Its intent was allowing our customers to override download locations for all plugins, so that only trusted pre-approved plugins could be downloaded. Since then, we've added `PluginDownloadURL` for a package, which is the default URL for that package's binary if it's shipped outside our Pulumi org. Currently, `PluginDownloadURL` takes precedence over `pluginDownloadURLOverrides`, which means it's impossible to override third-party package binary locations. This PR changes plugin source resolution to flip the priority of those two. If an override matches regex, its URL will take priority over the default `PluginDownloadURL` specified in the package. I have added tests to verify `pluginDownloadURLOverrides` with and without `PluginDownloadURL`. The second one fails before my change. Resolves #16058 ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/plugins
Plugin acquisition and resolution
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs
kind/enhancement
Improvements or new features
resolution/fixed
This issue was fixed
Hello!
Issue details
Today, you can use pluginDownloadURLOverrides to override plugins that don't have PluginDownloadURL explicitly set which is all Pulumi maintained plugins. The only problem is when attempting to use a plugin that does have PluginDownloadURL set, for example, one of the
PulumiVerse
plugins. In this case there is no way to override it today.The use case is to be able to configure all plugins to be downloaded from an internally hosted solution such as Artifactory. I will open a separate issue requesting the add of a Artifactory source as well.
Affected area/feature
Plugin Discovery and Sourcing
Additional Context
It likely requires a change in PluginSpec.GetSource here but not sure if there will be some additional work needed to override the URL and get it working correctly to construct a download url root for a internal hosted solution but that is speculative.
The text was updated successfully, but these errors were encountered: