i want to propose an improvement to many engineering flows with Java IaC: 1. engineer clicks a githubAction or any CI/CD preference 2. an artifact is built 3. engineer goes to a cloud provider of their choice e.g. Azure 4. engineer uses cloud-shell

wget

the artifact 5. artifact is a script a. script installs pulumi b. script asks for token to do pulumi login c. script runs pulumi up i. pulumi is smart enough to sort out the binary within the artifact and run the java app

Curious to understand the reason behind this workflow compared to the conventional approach of running

pulumi up

as part of the CI/CD pipeline.

That's a lot of "wait for human" and "human has opportunity to make mistakes" - so I suspect there is an interesting story behind that and I too am curious

@famous-mouse-60188 Have you already looked at Pulumi Automation API? With it you can build binaries/executables, which are very close to the process you've described. The resulting binaries download Pulumi CLI, do the login and let you automatically provision a stack.

sure thing. I came up with a process/system similar to Pluralsight sandboxes that allows you to have a cloud sandbox for up to 8 hours to run safe experimentation. what i do for azure is 1. go to cloud shell in the cloud sandbox 2. clone the repo 3. install JDK25, gradle, pulumi 4.

./gradlew clean build

5.

pulumi up

5 mins later i have a clean AKS cluster to run my experiments 6. once i am done to keep record in the pulumi app i do

pulumi destroy

I thought i could avoid step 2 to 4 by trying to have a Fat Jar or a java distribution of the gradle project.