Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since I need to work on a proposal for a change here (based on discussion @ filecoin-project/boost#715) I thought I'd get familiar with the codebase by attempting a conversion to unified-ci. Maybe there are objections to doing this here though?
Still needs registering in protocol/.github so we get automatic syncs.
Main changes:
err
checks in tests but it also found an interesting one in registry_test.go where a URL is modified with a noop, I'm not sure it's changed any test results though!The most interesting bit is trying to get Windows compatibility. In the end I skipped a few of the tests but the main problem seems like a real issue worth fixing at some point—there's no way to properly clean up resources on a Dagstore
Close
. It's very easy to have open file handles and Windows is a bit more strict about removing directories (temp for the tests) when there's open file handles. In particular, the mounts, as they go throughUpgrader
, have the.completed
file left open in many cases and there's no easy way to get it closed before end of test. Ideally a DagstoreClose
would handle this but it's not straightforward enough for me to wire all that up in this PR. The Context cancellation test presents a whole other set of issues around resource cleanup, you have open file handles stuck in the channel queue system that just gets dropped on the floor when the context is cancelled. We probably need to track active mounts internally and close them out properly at the end and also figure out how to wire the context through the necessary paths to also close them out on cancellation, although I'm not sure about that because contexts are handled inconsistently through the various API calls so it might be a challenge.