Hey again everyone 🤩 throughout our continued adoption of Pulumi, we've ran into something that may be a desired feature for many: • Additional custom resource option 'changeset' (name up for grabs, obvi) ◦ In essence, users could specify "pulumi up --changeset awsNetworking" or "pulumi up --changeset kubernetes" or "pulumi up --changeset fargate", etc. ◦ This would update only the resources tagged with that changeset name in the custom resource options, for example:

const dockerImage = new docker.Image('pulumiDockerImage', { build: {}, ... }, { dependsOn: [someNetworkingResource], changeset: ['fargate'] }

• This could be made, for example, to only update the resources tagged in current changeset as well as their downstream and upstream chain of "dependsOn" related resources. We've gotten into a pattern of splitting stacks in often logically/architecturally sub-optimal ways to manage our individual deployment scope, speed, complexity. This may involve notable design consideration/rigor to pull of in a safe manner but I do think it would be a feature valuable to MANY customers. Especially if it was coupled with a folder and file based 'checksum' resource to control what changesets should be automatically applied. For example:

const fargateRelatedGitRepoFiles = new pulumi.Changeset('pulumiChangeset', { name: 'fargate', includedFiles: [WHITELIST], excludedFiles: [BLACKLIST] })

Additional food for thought implementation pattern: • Create pulumi.Changeset resource -> only update things that list it in their 'dependsOn' as well as their upstream and downstream 'dependsOn' chains (eliminate CLI flags entirely) ◦ For example, if no defined changeset is active, we could just fall back to deploying everything (once again consideration/rigor design choice to be fleshed out)

I think projects are used for exactly that purpose. If you want to deploy "awsNetworking", then you have an "awsNetworking" project. The only thing this doesn't handle is when one resource might fit into multiple changesets. But that's probably a good thing, since that would mean that one resource could be destroyed via multiple different changesets, which would each have different resources dependent on that resource, which would lead to different results depending on what command you used to delete that one resource. Which would be bad 🙂

Maybe I'm missing something; how do projects help manage this?