white-balloon-205
white-balloon-205
adventurous-butcher-54166
08/30/2024, 9:44 AMincalculable-notebook-65772
08/31/2024, 11:11 AMnpm install && pulumi pre
and you are ready to go.
For this new approach, I wonder what we should do:
1. Should we add the 'sdk' folder to .gitignore? But every new developer must do the proper pulumi package add
command.
2. Should we store the generated SDK right into the repository? But we have many repositories - so it's not very DRY. Our bridged provider is rather big and has much code - so it looks like too much boilerplate.
3. What about the plugin part of the provider (the binary part)? Where is it stored? Is it also built on the developer's machine? But this leads to inconsistency - everybody is using different unique binaries 😃
In the end, the main questions are:
1. Should we get rid of the bridged provider in favor of this new way of building one?
2. How do we suppose to spread it across the company (how to make it a proper artifact dependency for everybody to reuse)?wonderful-waiter-817
09/01/2024, 5:54 AMechoing-dinner-19531
09/03/2024, 4:14 PMpackage add
3. There is no separate built plugin for dynamically bridged providers like this. They all use the same one binary which is the "pulumi-provider-terraform-provider" plugin
4. Maybe. Bridged providers are still supported, and support more things then the dynamic bridge currently supports (like being able to specify renames of properties). Use which ever one works better and easier for your specific use case.
2/5. We're working on making this better, but you can just use the existing pulumi package gen-sdk
command for these new dynamic bridged packages to just get an SDK library which you can then push to artifactory or similar. Again there's no separate plugin for these so you just need to distribute the SDK.millions-journalist-34868
09/16/2024, 10:57 PMechoing-dinner-19531
09/17/2024, 6:09 AMmillions-journalist-34868
09/17/2024, 9:18 PM