Still insert them into the database and associate them with namespaces,
but don't ever query them back out.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* docs: extend profiling guide
More tools.
* chore: fix docs lint for `localhost` links
* docs: do not duplicate tracing docs
* refactor: clean up `lint_docs` and strip anchors from relative links
* chore: Tool for automating arrow version update
* chore: Update datafusion and arrow/parquet/arrow-flight
* fix: update for changes in Arrow API
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
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).
__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
```
Emit also default values for fields in edit_db_rules, this way it's easier to know what to change.
Also simplify argument handling for edit_db_rules script
- enable quitting on error by fixing `read` (read with heredoc always exits with non-0 causing the script to bail out)
- enable quitting on unbound variables by pulling cleanup outside of main
- accept hosts with `http://` prefix or without (improve compat with iox client)
Now the script cleanly reports errors when you have a typo in the db name or hostname
There are a few yaks to be shaven before we have a good CLI for editing database rules.
This is a simple shell script that uses the grpc API to edit the database rules on a remote
IOx server. It fetches the rules, spawns your default text editor, waits until your editor quits,
and then calls the update API with the results of your local edit.
(if you use emacs, there is a thing called emacsclient which knows how to block until you closed
the buffer in your main persistent emacs)
Christopher M. Wolff
Carol (Nichols || Goulding)
Carol (Nichols || Goulding)
Luke Bond
Andrew Lamb
Marco Neumann
Raphael Taylor-Davies
Marko Mikulicic
Jacob Marble
Carol (Nichols || Goulding)