https://pulumi.com logo
#general
Title
# general
e

enough-grass-76480

03/07/2024, 5:35 AM
I'm trying to create a custom component for our company to use. I've got everything working just fine, but I have not been able to test it locally because of the plugin. If I publish the binaries to our github, everything works as expected. But if I want to make a change and just test it on a local project, I have not been able to figure out a way to run it without publishing everything to github. Currently I have been able to run
pulumi plugin install resource xyz v0.0.1 -f /bin/pulumi-resource-xyz
and now I just get an error about a pulumiplugin.yaml file not existing. I have not been able to find any documentation on this at all. Is there a step missing? Can someone provide some help or a link to some documentation that would be helpful?
e

echoing-dinner-19531

03/07/2024, 8:38 AM
Just put the plugin binary on PATH, or use
plugin install --file
to copy the file to the local plugin cache.
e

enough-grass-76480

03/07/2024, 3:00 PM
Sorry, what do you mean when you say "put the binary on PATH"? Also, isn't the second command basically what I have already tried?
And when you say local plugin cache, do you mean the
.pulumi/plugins/
folder? As I said in my original post, the plugin install command works successfully. But when running
pulumi preview
I get the error
error: failed to load plugin C:\Users\Aaron\.pulumi\plugins\resource-xyz-v0.1.3\pulumi-resource-xyz.exe: loading PulumiPlugin.yaml: open C:\Users\Aaron\.pulumi\plugins\resource-xyz-v0.1.3\PulumiPlugin.yaml: The system cannot find the file specified.
e

echoing-dinner-19531

03/07/2024, 3:42 PM
"PATH" as in the environment variable telling your shell where to find executables. e.g. likely you'll have C:\Users\Aaron\go\bin as a directory listed in PATH (or Path for windows) and if the plugin exe is in that folder it should get picked up. and yes
--file
is the same as
-f
, I think that expects to be pointed to the file itself, (i.e. pulumi-resource-xyz.exe) not the folder.
e

enough-grass-76480

03/07/2024, 3:43 PM
Ok, thanks. Sadly I have done both of those to no avail.
e

echoing-dinner-19531

03/07/2024, 3:43 PM
does anything get copied to ".pulumi/plugins" when you run install?
e

enough-grass-76480

03/07/2024, 3:43 PM
Yes
There is a folder with the new version and a single file in there. It doesn't have a file extension though.
e

echoing-dinner-19531

03/07/2024, 3:44 PM
did your original file have an extension?
e

enough-grass-76480

03/07/2024, 3:44 PM
No
e

echoing-dinner-19531

03/07/2024, 3:44 PM
ah well that's probably the issue. The windows code will be expecting to find an ".exe" file
e

enough-grass-76480

03/07/2024, 3:45 PM
Makes sense, the error indicates that it is still able to use that file though.
Should the binary generator create a .exe file?
e

echoing-dinner-19531

03/07/2024, 3:45 PM
yeh it should, how are you building the plugin?
e

enough-grass-76480

03/07/2024, 3:46 PM
just running
make install_provider
Using the base boilerplate makefile
e

echoing-dinner-19531

03/07/2024, 3:46 PM
e

echoing-dinner-19531

03/07/2024, 3:48 PM
I'd raise an issue on that repo, sounds like a makefile bug. Building the provider on windows ought to be an .exe file.
e

enough-grass-76480

03/07/2024, 3:49 PM
Hmm... ok, thanks. I did have to change a lot about this template to make it work. The only real change to the makefile was the property parameter on building the dotnet sdk.
Might be a bigger issue. Would you recommend using the boilerplate you provided instead?
e

echoing-dinner-19531

03/07/2024, 3:50 PM
no, the one your using should be the more recent and up-to date one. It's probably not been tested well on windows.
e

enough-grass-76480

03/07/2024, 3:50 PM
ah ok
Thanks for the help!