Hey, all. 👋 I'm somewhat new to Pulumi, and doing my first real work with the automation API in Go. I have two apps, one that creates resources in a stack, and another that uses the same stack to modify the resources. Ideally, I'd like to use an inline function in both cases. What I can't figure out is how to ensure I make just the modification I want, without deleting the resources already in the stack. With the CLI, I gather you'd run an import (maybe?), but the import functions in the API seem not to affect the inline function (which makes sense to me). Looking up each resource in the second app's inline function does work, but it's slow and cumbersome. Is there a better way that I'm missing?

What are you putting into the 2nd project's code? You should be leaving all the resources in there, all the time. You don't put just the changes you want in there: that is what causes all the other resources to be deleted.

Thanks! That much I'm pretty clear on. What I'm coding is kind of a handoff: one system programmatically creates infrastructure, and another (run by a different user with access to the .pulumi directory on cloud storage) makes modifications.

Stacks aren't per-user (normally). The best thing to do is for both users to use the same stack. No handover.

I think maybe I haven't been clear. I'm only using one stack. The app that creates the stack populates it with a set of resources that can be claimed and modified by users of the second app.

I don't understand why two records of a single resource is needed.

I'm not trying to make two records in the stack.

If you run Up on code that has already been upped, then you're not starting from scratch. The existing resoruces exist, and the new Up will be modifying them. If you are starting from scratch (and therefore, stuff is being created in duplicate), then you have a problem with the way your state is being managed.

I think that's the confusion. They're using different source code, but the same state file and credentials.

Then you need to change the way you're working. There is a 1:1 relationship between source code and state file. Two different source code files cannot use the same state.

That's what I'm doing.

That's your problem.

This isn't like with normal Pulumi, where I have my code in a directory with my yaml files, and it doesn't change.

Since you're changing the code, you must change the state. You cannot hand the existing state over without also handing the code over. The problem, unfortunately, is your business process.

I do understand that.

The technical solution isn't complicated, I don't think. It's just different from your original intention

Unfortunately, that solution only works if the code is static. As soon as the code is doing something like generating a unique ID, the second run doesn't produce the same resources as the first.

You could create a new stack, export it and the original stack, and carefully move bits of JSON from one file to the other. You'd need to change some provider URNs probably. It'd be tricky. Honestly, if you're generating code, then it should be easy to generate the pulumi import commands at the same time. However there is another alternative: since you're creating unique IDs per target user, then I think you should consider creating a target stack for that user too. And then just handing that stack over. You don't need to use the same stack every time you run the code: you can tweak your devA code to change the stack name each time you're starting from scratch.

Hmm. That idea of a non-automation-API stack to start with is an interesting one. It would definitely work for my use-case. Thanks again for all the time you spent on this! I appreciate it.

You can use an automation-api program to run a non-inline project. The project is separate from automation-api. Automation-api provides a convenience feature that allows you to put the project code directly into the automation-api program, but this isn't required (and, in my opinion, is a conflation of ideas that runs the risk of confusing people reading the code). Keeping the two things separate is a good idea in many (all?) cases.