Skip to content

[CI] Move pipelines to new setup for PROD#225

Merged
radical merged 9 commits intodotnet:mainfrom
radical:switch
Dec 4, 2025
Merged

[CI] Move pipelines to new setup for PROD#225
radical merged 9 commits intodotnet:mainfrom
radical:switch

Conversation

@radical
Copy link
Member

@radical radical commented Nov 24, 2025

TODO: support for testing PRs

@radical radical requested review from ericstj and joperezr November 24, 2025 18:34
ref: refs/tags/release

variables:
- name: system.debug
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming we don't want to keep this as true and was only meant to be used for debugging?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you help me understand why we need to make this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Help me understand why we need this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@radical radical merged commit 3733d33 into dotnet:main Dec 4, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants