-
Notifications
You must be signed in to change notification settings - Fork 62
save test outputs from failed GitHub Actions #546
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
Conversation
|
Commit 09405d6 seems to work at least somewhat. I deliberately injected a test failure that would leave a log file around. We have this output from the upload action: The artifact is hidden at the bottom of this page: And although it's the zip analog of a tarbomb, it seems to contain the log files: It does not appear to have picked up the database files though. |
|
Some weird things about this:
My real question at this point is: was the cockroachdb directory actually there at this phase? We'll see if the step-by-step debug output shows up for the next run. If not, I'll add a dummy step to print out everything in Update: I tried this locally and the directory wasn't there. We seem to clean this up even on unsuccessful tests. |
|
The latest change preserves the database directory when the Besides that, I still want to verify that the artifacts generated for the latest build include what they should. |
|
The artifact from the latest change looks like what I'd expect: It also doesn't have any extra database directories. |
|
Here are the remaining things I'd like to do on this PR:
|
|
Verifying the artifacts from the run on 8a9c27d: (namely, we have one log file at the root, and it names the temporary directory, which is the only other thing contained at the root, and that directory appears to look like a complete cockroachdb data directory) Similarly for the MacOS artifact: |
| #[tokio::test] | ||
| async fn test_organization() { | ||
| let logctx = dev::test_setup_log("test_database"); | ||
| let logctx = dev::test_setup_log("test_organization"); |
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.
Unrelated typo in the log file name that I found while doing this.
| #[allow(unused_must_use)] | ||
| if let Some(temp_dir) = self.temp_dir.take() { | ||
| temp_dir.close(); | ||
| /* |
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.
This is mentioned in the PR comments: we now deliberately save the database directory if you don't explicitly clean it up after a successful test.
| assert_eq!(rows.len(), 0); | ||
| client2.cleanup().await.expect("second connection closed ungracefully"); | ||
|
|
||
| db1.cleanup().await.expect("failed to clean up first database"); |
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.
These tests always should have been cleaning up the database instead of relying on the best-effort Drop impl. Now that the Drop impl doesn't clean these up any more, they were leaking the directory without this fix.
andrewjstone
left a comment
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.
AFAICT, this should work :)
| - name: Archive any failed test results | ||
| if: ${{ failure() }} | ||
| # actions/upload-artifact@v2.3.1 | ||
| uses: actions/upload-artifact@82c141cc518b40d92cc801eee768e7aafc9c2fa2 |
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.
Just curious, why the sha rather than a version (which requires a comment) ?
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'm not sure how well-founded it is, but following the advice in https://julienrenaux.fr/2019/12/20/github-actions-security-risk/.
Related to #542. Do this for GitHub Actions too.
I haven't tested this yet.