Deploying an Aspire solution with Postgre Flexible Server using azd works only the first time

[pautx24]

Context
I've got an Aspire .NET app. It has a backend API that reads from a server.

The DB server is defined as follows in the AppHost Program.cs:

var db = !builder.ExecutionContext.IsPublishMode
	? builder
		.AddPostgres(AspireServices.DbServer, password: builder.AddParameter("DbPassword", secret: true), port: 53875)
		.WithDataVolume()
	: builder
		.AddPostgres(AspireServices.DbServer)
		.AsAzurePostgresFlexibleServer();`

It works perfectly in local.

I deploy from Az DevOps, using the build pipeline.

Basically it runs the commands:

        azd provision --no-prompt
        azd deploy --no-prompt

As far as I know, the provision step generates a KeyVault with the Postgres Server connection string. That secret is then provided by biceps in the deployment time to whatany service has reference to the Postgre DB.

Issue: when deploying to Azure the DB connection string gets lost the second time

On every run, on provision time, a new secret entry of the connection string is created in the KeyVault, and when providing the secrets to the services when deploying them, they are wrong.

Any thoughts or ideas about this?

[davidfowl]

cc @vhvb1989

[pautx24]

The workaround I used to make it work has been to provide the DB username & password as pipeline variables. Then pass those into the provision step to Bicep.

After a few working deployments, I finally get the " (-) Skipped: Didn't find new changes."

[vhvb1989]

@pautx24 , usually you would run azd pipeline config --provider azdo to let azd to configure your pipeline.
See: https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/configure-devops-pipeline?tabs=azdo#advanced-features

During azd pipeline config .... azd will prompt for any required params and make sure to make them available in CI/CD.

[pautx24]

Yeah, that's exactly what I did, and I didn't matter when comparing the deployed resource group vs the one I was deploying. Even though nothing had changed.

Actually as I said, after few deployments it suddenly got the comparisison right and I now have the expected behavior...

Can I help you somehow sharing some aditional details or you prefer to close it for good?