[CI] Move pipelines to new setup for PROD #225
Conversation
.. if an old container cannot be removed - it does not need to block a new deployment.
| ref: refs/tags/release | ||
|
|
||
| variables: | ||
| - name: system.debug |
There was a problem hiding this comment.
Assuming we don't want to keep this as true and was only meant to be used for debugging?
There was a problem hiding this comment.
Retained from existing code, but I can drop this.
| - name: resourceGroupName | ||
| value: 'source.dot.net' | ||
|
|
||
| # Note: the subscription name variables need to be at the pipeline level to be used in the AzureCLI tasks. |
There was a problem hiding this comment.
Just double-checking, is this right or just AI- slop?
| </Target> | ||
|
|
||
| <Target Name="PrepareV1" DependsOnTargets="PrepareOutput;ResolveHashV1" Outputs="%(ClonedRepository.Identity)"> | ||
| <Target Name="PrepareV1" DependsOnTargets="PrepareOutput;ResolveHashV1" Outputs="%(ClonedRepository.Identity)" Condition="@(ClonedRepository->Count()) > 0"> |
There was a problem hiding this comment.
Can you help me understand why we need to make this change?
There was a problem hiding this comment.
This helps to build even if we don't have any V1 repos. Just a cleanup and will help when we have dropped all the V1 repos. I was hitting it when trying to run with reduced subset of repos for testing, and it would still require at least one V1 repo to be enabled.
| public void Configure(IApplicationBuilder app, IWebHostEnvironment env) | ||
| { | ||
| // Configure forwarded headers for Azure Front Door | ||
| app.UseForwardedHeaders(new ForwardedHeadersOptions |
There was a problem hiding this comment.
Due to some recent changes, we may need to configure known proxies here. We should chat with Brennan about this one.
| /// </summary> | ||
| public static class HealthCheckResponseWriter | ||
| { | ||
| public static Task WriteResponse(HttpContext context, HealthReport healthReport) |
There was a problem hiding this comment.
Help me understand why we need this?
There was a problem hiding this comment.
We are adding the health endpoints so it can explicitly check if the storage also works. And when trying to debug an issue with deployment or the webapp, we will be able to enable the detailed endpoint to see if it might be failing to access storage, and why. The detailed endpoint is enabled only for development runs or via an environment variable.
In the existing code we only check a particular url that we know will be served from storage.
2 participants
TODO: support for testing PRs