1. by default use the repo where the `git-log-pr` script is located in, allowing it to be called
from other scripts in other repos (e.g. k8s-idpe) without too much cerimony
2. allow the git repo to be overriden with the `-C` flag (like the `git` command itself)
3. add a `--commits` flag which prints also commit shas in addition to PR numbers
4. GH merge commits contain the PR title as the body; if present use that instead of using the `gh` cli (which is slow and requires this tool to be installed).
* test: add test for operations.system_tables
* fix: only show operations for current database
* fix: update test
* fix: improve test
* refactor: filter in Schema provider rather than in job tracker
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
__Scenarios__
You may know the git sha of what's running in the staging cluster,
and you may know the sha of the latest built image is, but will upgrading to a new
version include the PRs I'm interested in?
Or alternatively: I noticed in the dashboard that IOx was working fine until
we rolled out a new version. Which PRs were included in this new rollout?
__Description__
Getting the answers to the scenarios above is surprisingly hard, because scanning
our git history is complicated by the fact that just about anybody uses a different
merging technique.
This script does the right magic to skim through all that cruft and get the answers.
__Demo__
```console
$ ./scripts/git-log-prs 8376983b74311df970339e106c62ce4038b20e5f..
1330
1336
$ ./scripts/git-log-prs 8376983b74311df970339e106c62ce4038b20e5f.. --titles
1330 feat: Make background task period configurable
1336 feat: Build a perf_image image for every commit in main
```
When we get the flatbuffers, we won't have the server ID in addition to
the flatbuffers-- it's in the flatbuffers. But we want to validate the
`ServerId` once when the `SequencedEntry` is created so that its
`server_id` method can assume it has a valid `ServerId`.
Pre-sized channels get full when the results to send over them are larger than the capacities. This causes significant runtime overhead and slows down query performance.
This commit removes the intermediate channels. The potential downside to this approach is there may be more buffering which could increase memory usage during query and also block a thread for longer periods of time.
Andrew Lamb
kodiakhq[bot]
Edd Robinson
Marko Mikulicic
Raphael Taylor-Davies
Nga Tran
Carol (Nichols || Goulding)