Skip to content

Conversation

@snprajwal
Copy link
Contributor

@snprajwal snprajwal commented Oct 29, 2025

Summary

The directory monitoring tests check for whether the documentation is rebuilt if the documentation catalog is edited when running a live server with docc preview. These tests assumed an extremely generous timeout of 5 seconds for changes to the directory, and 10 seconds for a lack of change. Thus, they ran much slower than the rest of the test suite. The timeouts have been reduced to a more reasonable threshold of 1.5 seconds, which still succeeds with throttled CPU resources.

Dependencies

N/A

Testing

This was tested by restricting CPU resources to 20% of a single core and running the tests 100 times:

for i in $(seq 1 100); do cpulimit -i -l 20 swift test --filter DirectoryMonitor; done

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • [ ] Added tests
  • Ran the ./bin/test script and it succeeded
  • [ ] Updated documentation if necessary

@snprajwal
Copy link
Contributor Author

@swift-ci please test

The directory monitoring tests check for whether the documentation is
rebuilt if the documentation catalog is edited when running a live
server with `docc preview`. These tests assumed an extremely generous
timeout for receiving the directory change signal, and ran much slower
than the rest of the test suite. The timeouts have been reduced to a
more reasonable threshold that succeeds even with throttled resources on
a single-core machine.
Copy link
Contributor

@d-ronnqvist d-ronnqvist left a comment

Choose a reason for hiding this comment

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

Only one of these changes make the directory monitor test faster, the rest only make them more fragile without running faster.

Comment on lines -83 to +87
wait(for: [updated], timeout: 5.0)
wait(for: [updated], timeout: 1.5)
}

if isTreeReloadExpected {
wait(for: [reloaded], timeout: 5.0)
wait(for: [reloaded], timeout: 1.5)
Copy link
Contributor

Choose a reason for hiding this comment

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

These timeouts don't speed up the test as long as it passes. Even if I increase both of these to 100 second testMonitorUpdates only takes ~5 seconds for me to run locally.

Copy link
Contributor

Choose a reason for hiding this comment

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

If we want this to succeed faster then we'd need to change the 1 second throttle time here.

}

wait(for: [didNotTriggerUpdateForHiddenFile], timeout: 20)
wait(for: [didNotTriggerUpdateForHiddenFile], timeout: 2)
Copy link
Contributor

Choose a reason for hiding this comment

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

This also doesn't speed up the test as long as it passes. Even if I increase both of these to 200 second testMonitorDoesNotTriggerUpdates only takes ~20 seconds for me to run locally.

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