Pulumi Automation API cannot correctly import components.

[kryptt]

What happened?

We have a custom component we wrote to homogenize how we declare our IAC. It essentially just has some thin wrappers around the AWS plugin.

Our devops team wrote this component (package) in pulumi-ts and run gen-sdk --local --language java to generate a maven jar we assume is usable from any one of our projects.

Once deployed as a jar in our m2 repository and brought in as a dependency for building our java based automation api application we get the following error:

[71] error: Could not automatically download and install resource plugin 'pulumi-resource-atn-iac-components' at version v0.0.0, install the plugin using `pulumi plugin install resource atn-iac-components v0.0.0`: error downloading provider atn-iac-components to file: failed to download plugin: atn-iac-components-0.0.0: 403 HTTP error fetching plugin from

Like I started mentioning before, this isn't a public plugin and there's very little in the automations API on how to procede from here; I asked in the slack channel about this and was redirected towards creating this issue.

Tnanks.

Example

simply generate and publish any component and try to import it via the java automations api.

Output of pulumi about

N/A this is an automations application

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[lunaris]

Hi @kryptt; thanks for reporting this issue and sorry for the inconvenience it is causing you. It looks like the SDK you've generated is the right one -- the question now is, where is Pulumi going to find the component that responds to it. Currently Pulumi is trying to install the component using some default logic, which probably won't work since your component doesn't have a public URL it's aware of.

Depending on your use of the automation API, you might be able to make this work by adding a packages block to the Pulumi.yaml of the project you are managing with the API. If you are using inline programs, it might be a bit fiddlier, but hopefully still doable. Are you able to provide more information on what you're trying to achieve? Hopefully we can figure this out from there then.

[kryptt]

Sure,

I am indeed using inline programs as I currently don't have a Pulumi.yaml in that project.

What we're trying to do is simply leverage some common definitions from our platform engineering team into a coordinator of sorts we're writing up in Java.

[Frassle]

I think we might need to extend automation api to be able to define package blocks for inline programs. ProjectSettings has the older plugins section which could be used for this, but the new packages section is easier to work with.

[kryptt]

This will be very useful for us, since we had to abandon our tight integration with our build tool (mill) and are currently struggling with several duplicate buildspec.yaml files lying around all over the place...