Remove workarounds in HealthChecksUI sample

[DamianEdwards]

Removes workarounds in the HealthChecksUI sample that should no longer be required now that dotnet/aspire#3786 and dotnet/aspire#3749 are fixed.

NOTE: I'm currently deploying the sample via azd to ensure it still works. Will update here to confirm outcome once done.

OK so seems there's a regression from this change. I'll investigate:

LOL it came good after a few seconds 😄

azd up output:

Packaging services (azd package)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: ****
Location: ****

  You can view detailed progress in the Azure Portal:
  *****

  (✓) Done: Container Registry: acrrfuiqiqdyuxji (9.938s)
  (✓) Done: Log Analytics workspace: law-rfuiqiqdyuxji (18.178s)
  (✓) Done: Container Apps Environment: cae-rfuiqiqdyuxji (1m36.401s)

Deploying services (azd deploy)

  (✓) Done: Deploying service apiservice
  - Endpoint: https://apiservice.internal.delightfulbay-32d021f3.westus.azurecontainerapps.io/

  (✓) Done: Deploying service cache
  - Endpoint: https://cache.internal.delightfulbay-32d021f3.westus.azurecontainerapps.io/

  (✓) Done: Deploying service healthchecksui
  - Endpoint: https://healthchecksui.delightfulbay-32d021f3.westus.azurecontainerapps.io/

  (✓) Done: Deploying service webfrontend
  - Endpoint: https://webfrontend.delightfulbay-32d021f3.westus.azurecontainerapps.io/

  Aspire Dashboard: https://aspire-dashboard.ext.delightfulbay-32d021f3.westus.azurecontainerapps.io

SUCCESS: Your up workflow to provision and deploy to Azure completed in 5 minutes 4 seconds.

[joperezr]

Changes LGTM. Out of curiosity, if we wouldn't have ingested 9.0 GA yet (with the fixes), and we tried doing these changes, would a test(s) have failed as part of CI in this PR? If not, should it and should we add a test for it?

[DamianEdwards]

Out of curiosity, if we wouldn't have ingested 9.0 GA yet (with the fixes), and we tried doing these changes, would a test(s) have failed as part of CI in this PR? If not, should it and should we add a test for it?

Not for this specific change, as it relates to publishing. We don't have any tests that verify the output of publish currently. The cheapest thing we could do is add tests to verify the manifests generated are what's expected. Of course any change that impacts the manifest would then require the "expected state" manifest to be updated. Logged #572 to track that idea.

[davidfowl]

Looks good!

[davidfowl]

I don't think you need this branch

aspire-samples/samples/HealthChecksUI/HealthChecksUI.AppHost/HealthChecksUIResource.cs

Lines 158 to 160 in 4969bf2

	context => context[urlEnvVarName] = isPublishing
	? ReferenceExpression.Create($"{healthChecksEndpoint}/{probePath}")
	: new HostUrl($"{healthChecksEndpoint.Url}/{probePath}")));