-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use Files.createTempFile #141
Conversation
Pull Request Test Coverage Report for Build #383Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build #384Details
💛 - Coveralls |
This reverts commit 8ec486b.
Pull Request Test Coverage Report for Build #385Details
💛 - Coveralls |
The Windows build seems to be failing because:
This seems to be a CI / Github Actions issue rather than related to any change in this PR. edit: Not sure if this is at all related: actions/runner-images#10004 Reverting to windows-2019 fixes for me, which does not seem like the same as what's described there. Maybe the 2019 image has already been fixed. |
Pull Request Test Coverage Report for Build #386Details
💛 - Coveralls |
schedule: | ||
# Every Sunday, rerun | ||
- cron: "0 12 * * 0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this re-run? What would the test suite catch when re-run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like it's often my experience that the CI process for this repo turns out to have some problem when I go to make a change here, and I'd rather be alerted to that proactively rather than when trying to fix something else. Perhaps the CI issues encountered here are indeed not something that would be usefully caught by this; if that's the case then maybe we don't need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. There definitely seems to be some flakiness involving the docker images. I wonder if it would make more sense to pull the Dockerfile
into the repo and have the test suite build its own docker image to then run? I guess that would depend on how long it takes to build the image.
Pull Request Test Coverage Report for Build #387Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build #388Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build #389Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build #390Details
💛 - Coveralls |
Fixes #140, using
Files.createTempFile
is preferable since it will have more restrictive permissions by default. I don't think we can rely on the file being only owner-writable since that is not in the Javadoc. From what I understand, Posix permissions will cause an exception if not supported by the OS, thus we have to check the OS.