[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.
| </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.
There was a problem hiding this comment.
@radical we aren't building any V1 repos now, locally I've confirmed it's a regression from this change.
I don't understand why this condition would be needed in the first place. I'm also trying out locally with just a subset of repos (even with just a single V1 repo vs a single V2 repo) and I'm getting no errors without the condition.
Fix: #246
| 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.
3 participants
TODO: support for testing PRs