Skip to content

[tests] Enable Aspire.Hosting.Testing, and Aspire.Hosting tests that use docker to run on the build machine#4500

Merged
radical merged 41 commits intodotnet:mainfrom
radical:hosting-testing-build
Jun 21, 2024
Merged

[tests] Enable Aspire.Hosting.Testing, and Aspire.Hosting tests that use docker to run on the build machine#4500
radical merged 41 commits intodotnet:mainfrom
radical:hosting-testing-build

Conversation

@radical
Copy link
Member

@radical radical commented Jun 13, 2024

There is work in progress to get tests like Aspire.Hosting.Testing, and Aspire.Hosting running on helix. Meanwhile, we can have the tests run on the build machine, at least for linux which has docker installed, by simply removing/updating the test attributes blocking them.

  • Remove [LocalOnlyFact/Theory] attributes in favor of [RequiresDocker]
  • Remove unncessary SkipOnHelix attributes from SchemaTests
  • Install devcerts on Linux/build machine
  • Fix path construction for nodeapp so it correctly works on linux
  • Split, and fix node/npm tests to work on CI whenever the relevant tool is available.
Microsoft Reviewers: Open in CodeFlow

@ghost ghost added the area-integrations Issues pertaining to Aspire Integrations packages label Jun 13, 2024
@radical radical force-pushed the hosting-testing-build branch from 37f978c to a85b721 Compare June 13, 2024 21:44
@radical radical changed the title [tests] Enable docker based tests on build machine [tests] Enable Aspire.Hosting.Testing, and Aspire.Hosting tests using docker to run on the build machine Jun 13, 2024
public async Task HttpClientGetTest()
{
var httpClient = _app.CreateHttpClient("mywebapp1");
await Task.Delay(3000);
Copy link
Member Author

Choose a reason for hiding this comment

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

@ReubenBond @DamianEdwards This PR enables the hosting.testing tests to run on CI. But two tests fail - HttpClientGetTest, and SelectsFirstLaunchProfile with connection refused. And it seems to be due to webapp not being ready. I added a Task.delay to confirm that, and it does work. But what is the correct way to have the test run only once the webapp is ready?

Copy link
Member

Choose a reason for hiding this comment

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

You should configure the HttpClient with resilience so that it retries. Once #4444 goes in you'll be able to at least wait for the resource to transition to the "Running" state before attempting to send the request, but you still need the retries.

Copy link
Member Author

Choose a reason for hiding this comment

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

Should that be added to the Aspire.Hosting.Testing api? I added that as an extension method in the test right now.

Copy link
Member

Choose a reason for hiding this comment

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

HttpClient default resiliency pipelines aren't composable so we don't add it by default as there'd be no way to remove or modify it. The test templates have code in them that adds resiliency in the test itself.

Copy link
Member Author

@radical radical Jun 14, 2024

Choose a reason for hiding this comment

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

Looking at the template, I added this to the TestingAppHost1.AppHost/Program.cs:

builder.Services.ConfigureHttpClientDefaults(http =>
{
    http.AddStandardResilienceHandler();
});

@radical radical changed the title [tests] Enable Aspire.Hosting.Testing, and Aspire.Hosting tests using docker to run on the build machine [tests] Enable Aspire.Hosting.Testing, and Aspire.Hosting tests that use docker to run on the build machine Jun 13, 2024
@radical radical marked this pull request as ready for review June 13, 2024 21:51
// Relative to this project so that it doesn't changed based on
// where this code is referenced from.
var path = Path.Combine(Projects.TestProject_AppHost.ProjectPath, @"..\nodeapp");
var path = Path.Combine(Projects.TestProject_AppHost.ProjectPath, "..", "nodeapp");
Copy link
Member Author

Choose a reason for hiding this comment

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

If the nodeapp fails to start for some reason, then no error is being surfaced. @ReubenBond

@radical radical requested a review from eerhardt June 13, 2024 23:45
@radical radical marked this pull request as draft June 13, 2024 23:45
… to wait for all the endpoints to get allocated

var token = new CancellationTokenSource(TimeSpan.FromMinutes(1)).Token;

await Task.Delay(5000);
Copy link
Member Author

Choose a reason for hiding this comment

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

@ReubenBond I added a delay here because the first client.GetStringAsync($"{httpEndPoint}urls" returned only the http endpoint. But the second invocation got both http, and https. Does this need to wait for all the endpoints to get allocated?

Copy link
Member Author

Choose a reason for hiding this comment

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

Should the API surface something (event?) for the endpoints getting allocated?
For this test, we could either use IDistributedApplicationLifecycleHook.AfterEndpointsAllocatedAsync or retry a few times in a loop.

Copy link
Member Author

Choose a reason for hiding this comment

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

The tests have an existing class for the hook which I tried to use here - https://gist.github.com/radical/7ef257229178c36f6b72ffd09f7e0b79#file-test-cs-L22-L27

But running the test with CWLs added to print the results from /urls:

Got urls from http://localhost:1234/urls: ["http://localhost:1234"]

Got urls from https://localhost:57048/urls: ["http://localhost:1234","https://localhost:57051"]

The first call is missing the https endpoint. Did the AfterEndpointsAllocatedAsync get invoked too early? Or am I missing something else?
@ReubenBond @DamianEdwards

@radical radical requested a review from mitchdenny June 13, 2024 23:53
@radical radical marked this pull request as ready for review June 20, 2024 01:53
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
Copy link
Member

@eerhardt eerhardt left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@radical
Copy link
Member Author

radical commented Jun 20, 2024

Added some debug bits, so don't merge before that is removed.

This reverts commit cb206dc.
@dotnet-bot
Copy link
Contributor

‼️ Found issues ‼️

Project Coverage Type Expected Actual
Aspire.RabbitMQ.Client Branch 80 77.5 🔻

Full code coverage report: https://dev.azure.com/dnceng-public/public/_build/results?buildId=714974&view=codecoverage-tab

@radical radical merged commit fb97eda into dotnet:main Jun 21, 2024
@radical radical deleted the hosting-testing-build branch June 21, 2024 00:35
@radical
Copy link
Member Author

radical commented Jun 21, 2024

How did the coverage go down here?!

‼️ Found issues ‼️

Project Coverage Type Expected Actual
Aspire.RabbitMQ.Client Branch 80 77.5 🔻
Full code coverage report: dev.azure.com/dnceng-public/public/_build/results?buildId=714974&view=codecoverage-tab

How did the coverage go down here?!

@radical
Copy link
Member Author

radical commented Jun 21, 2024

The number from the previous main build is 75%, so this should be an increase. Though, again, I'm not sure why with this PR. Maybe some extra bits are getting covered in the docker dependent tests.

cc @RussKie

@RussKie
Copy link
Contributor

RussKie commented Jun 21, 2024

The number from the previous main build is 75%, so this should be an increase. Though, again, I'm not sure why with this PR. Maybe some extra bits are getting covered in the docker dependent tests.

It could be due to the code coverage reporter not correctly reporting the numbers... ¯\_(ツ)_/¯ You'd need to look into the actual cobertura.xml.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=714972&view=logs&j=8cf0092d-1f6c-522b-3c27-9f632d33f4f3&t=b92e38fc-0165-5b68-b32b-2eef48c1a225&l=9
image

The thing is - the new version was broken and unusable, and I made numerous attempt to contact the team responsible in the past two years but they wouldn't listen....

@github-actions github-actions bot locked and limited conversation to collaborators Jul 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-integrations Issues pertaining to Aspire Integrations packages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants