feat: Reintroduce Papercut module #1268
Conversation
…endpoint for Papercut WebUI Service
✅ Deploy Preview for testcontainers-dotnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…ntainers all at once fighting over resources reduction
…nto feature/reintroduced-papercut # Conflicts: # build.cake
…nto feature/reintroduced-papercut
… pipelines though so we don't destroy developer boxes with images we didn't create
There was a problem hiding this comment.
Hey Liam, as I mentioned on Slack, thanks so much for the PR and all the effort you put into it, really appreciated!
I updated the Cake script to run the tests sequentially for now (I know it's slower, but I have some thoughts on that below). Could I kindly ask you to merge the develop branch and revert the changes related to Cake and the pipeline for now? I'd prefer to keep the PRs separate.
I've been thinking about a few things:
- I think we should avoid pruning images after each test (assembly). I want to prevent removing all images on a developer’s machine when someone uses the Cake task.
- I'd prefer using an MSBuild target (this works from a CLI and an IDE too) that developers can opt into, for example, using an environment variable. The MSBuild target could then parse log messages and prune only the images actually used by the tests.
- I changed the pipeline to run sequentially to make reading the log messages easier, it was quite messy and difficult to follow before. My idea is to spawn multiple runners for the different modules to run the tests in parallel (in the future). We already have the implementation to merge code coverage from multiple runners, and I think this would have a few advantages: it should run much faster, be more stable, and it would eliminate the need to free up disk space, so we don’t need to worry about the size of the images.
WDYT?
# Conflicts: # build.cake
…nto feature/reintroduced-papercut
|
Hi @HofmeisterAn |
HofmeisterAn
changed the title
What does this PR do?
Added a wait strategy using HTTP request is succeeded for the health endpoint for Papercut WebUI Service.
This should stop the failing on the pipeline raised here #1265
Why is it important?
The wait strategy allows the container to be ready for testing and usage when starting up especially in a very busy environment
Related issues
None
How to test this PR
Tests pass now when running dotnet cake
Follow-ups
Hopefully, there is enough here to stop the issues @HofmeisterAn was having when doing other modules