-
Notifications
You must be signed in to change notification settings - Fork 108
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
Update b1.0 #3601
Update b1.0 #3601
Conversation
This combines a few issues: first, I've wanted to filter based on the unpacked tarball size, but some tarballs are beyond the range of the SQL `INTEGER` type and cause SQL cast errors -- change the interpretation of the `int` filter and sort type to `BigInteger`. Also cleans up the logging around retried Sync transaction errors, only logging warnings when it can't determine that the error is a PostgreSQL serialization error. (I hope: this is hard to provoke in casual testing.) Finally, clean up the logging of cached unpacked size by avoiding two separate logs (without dataset name) on unpack, and adding a log of the final unpacked size when we compute it.
Sort datasets by uploaded time
* PBENCH-1307 End time column update
Undable to update date
* PBENCH-1300 Visualization Page Pagination
Display metadata modal is empty
Overview page displays Public datasets
…s#3595) * Another tweak to intake metadata problems Make sure we can't end up with undefined `metadata`. Record details of `metadata.log` access to `run.controller` without adding a ton of separate messages.
* PBENCH-1216 TOC page update
* Minor logging cleanup Minimize cache logging: details were useful when cache management first went in, but are now disruptive during ops review.
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.
OK, so why did GitHub re-integrate commits already on the branch? That's ... weird, and maybe a bit disturbing. But ultimately I'll trust your comparison of the final state, and I don't see anything extremely obviously different from what I think I expect. 😕
I think the blame (eh-hem) falls on Git. If I look at the history tree, the common ancestor between
which, on the
and then by the same six commits which are on the So, (I theorize) now that we're merging So, I don't really like it, but it seems to make sense, and it seems to produce the correct result. (And, really, we should not be rebasing the But, all's well that ends. |
This PR brings the
b1.0
branch up to date with themain
branch. The only difference between the two is the contents ofjenkins/branch.name
.PRs #3592 through #3598 will be new to this branch; the commits for PR #3586 through #3591 are already on the
b1.0
branch, so I'm not sure why they are included in this PR.