Summary:
To support VPNless access, we need to fetch the remote config through x2pagentd, setting a CAT related header.
I tweaked the order of config loading so the remote config fetch has the system "auth_proxy.unix_socket_path" config setting available.
Reviewed By: quark-zju
Differential Revision: D44263216
fbshipit-source-id: 5b8e6c4c9c7a5ab22ecfcfa62a537623931a63bf
Summary:
Now that we support passing `--draft`, we need to render diffs as drafts in the UI.
This diff adds support for showing draft github PRs.
We need to fetch `isDraft` in our graphql. For some reason, this isn't a PR `state`, even though it supercedes the OPEN state. So although we fetch it as `isDraft`, it's much more convenient in our code to treat it as another state.
Reviewed By: muirdm
Differential Revision: D44343542
fbshipit-source-id: 3cd324d44b6345da3e92e9a3f1ffccac3c8921eb
Summary: A small oversight in the SubmitAsDraftCheckbox meant that in the "commit" mode, the draft checkbox wouldn't appear even though it's valid to submit as a draft. We should just explicitly pass `[]` when creating a new commit to submit, and then allow that case in our logic.
Reviewed By: quark-zju
Differential Revision: D44342932
fbshipit-source-id: 3aaf4c00194a19030fad8b5b910bcf08d2354803
Summary:
Small fix, if you submit for the first time in a github repo, it will ask if you want to use ghstack or sl pr. That submit process doesn't respect the draft checkbox you may have selected in the commit info.
I don't think we need to show the draft checkbox _again_ in the interstitial confirmation, since you already selected it before pressing submit, which is the normal condition for using the draft checkbox.
Reviewed By: muirdm
Differential Revision: D44342933
fbshipit-source-id: c720153dd103b98a7936bf3dc3e76ff608007bce
Summary:
ObjectStore.h includes too many headers. Replace several with forward
declarations.
Reviewed By: xavierd
Differential Revision: D44323736
fbshipit-source-id: 944cd72fd758df4363493f87a573d91245a45b6a
Summary:
All of these configs have been enabled by default for a bit, let's change their
default before we can fully remove them from the code.
Reviewed By: genevievehelsel
Differential Revision: D44234768
fbshipit-source-id: 922093a64b91c9a45f84349ea50afc1c08fd6a39
Summary:
XLOG(DFATAL) is non-fatal in production builds, so it's possible we'll fall through here. It's unclear what the compiler will do in this scenario, so let's make sure we return folly::unit to avoid any compiler weirdness.
This may be causing a frequent crash on Sandcastle hosts where we're panicking after logging this DFATAL error. The crash looks like it's coming from an invalid instruction, so falling through here could be the root cause.
Reviewed By: xavierd
Differential Revision: D44314543
fbshipit-source-id: 6d23ffa221d7af4e7be641349eab1eb9027443a1
Summary: Basename suffix skeleton manifests are not been warmed by the warm bookmark cache. This means requests that need these are slowed down while they are derived. Add a warmer for them.
Reviewed By: yancouto
Differential Revision: D43906545
fbshipit-source-id: e1f77b5fe2a7a4512bfc49bf8047afef9b441fa9
Summary: This doesn't appear used anymore (superseded by phabdiff and phabstatus extensions).
Reviewed By: evangrayk
Differential Revision: D44263215
fbshipit-source-id: 323da45474a6cd1f9df730fdce23f4f42e836fb8
Summary:
do not sample out slow requests in edenapi replay
we already don't sample them in mononoke test perf
if we also don't sample here, we will have more insight in those and also we will be able to replay
Reviewed By: clara-9
Differential Revision: D44258777
fbshipit-source-id: 597fc475062b23eb24b0c61024eea9046b808420
Summary: Deduplicate reads of large blobs by using a shared future for any in-flight reads. If another read for the same key comes in after then we will read it again, but there should be at most one read in flight for a particular key at a time.
Reviewed By: Croohand
Differential Revision: D44183928
fbshipit-source-id: d6911422a6e16b3dd246dd48cbce4390e6856940
Summary: Make it possible for tickets to become `'static` by using `std::borrow::Cow` for the borrowed values, and converting to the owned variant if needed. We will use this to shared futures that hold a ticket.
Reviewed By: Croohand
Differential Revision: D44262842
fbshipit-source-id: 2c549b2f2f3724c6485b41463b973273211dfe77
Summary:
The `awaited` boolean on the `Ticket` structure and corresponding `Drop` makes it impossible to move out of the fields of `Ticket`. This is inconvenient, especially since it only enables a unit test check.
Move the field to a structure that's internal to the `Ticket`. We still check for failure to await, as dropping the `Ticket` with a `CheckAwait` that hasn't been marked as awaited will still panic during tests when the inner `CheckAwait` gets dropped.
Reviewed By: Croohand
Differential Revision: D44270321
fbshipit-source-id: 29429c40243b31dcc1a5046969b85fb7a15fd0aa
Summary: This log was useful while we were testing the new commit graph, but now it is too noisy and should be removed.
Reviewed By: liubov-dmitrieva
Differential Revision: D44297423
fbshipit-source-id: c9969d4a0b4709ea2065f19508ae6b51a7ee6baf
Summary: We previously only logged the error code of any failed Python commands. This means we have no insight into why Python commands were failing.
Reviewed By: chadaustin
Differential Revision: D44111246
fbshipit-source-id: 8c2f66457761ddd8b90ff4fb307152cd27ffa00a
Summary:
During checkout, these 2 are called a large amount of time, let's make sure we
have some telemetry so we can understand how much time is spent doing
invalidation during checkout.
Reviewed By: chadaustin
Differential Revision: D44311711
fbshipit-source-id: 5af62fe7fd4b37972458bc545bfaa2f4b4d2ca53
Summary:
This makes lifetime easier to reason about, and allows easier use of
DurationScope (see next diff).
Reviewed By: chadaustin
Differential Revision: D44311712
fbshipit-source-id: 1f9f4cbcc59bafeb464e2b39a248958cedaf9ca6
Summary:
Running the benchmarks/random_writes.cpp benchmark on all power of 2 from 4KiB
to 1MiB shows that 16KiB has the best tradeoff between fast random writes and
fast streaming writes.
Reviewed By: chadaustin
Differential Revision: D44320693
fbshipit-source-id: 2d1839caca3c30acdb6ffc675710a68359d03a76
Summary:
This one slipped through D44263797 and allows for integration tests to be run
with Buck2 on macOS.
Reviewed By: fanzeyi
Differential Revision: D44315942
fbshipit-source-id: d2de0773ba68f13fca9e8d5c067b82653646c757
Summary:
use `sl drawdag` to create test histories in integration tests. This is easier to read and quite powerful. Our tests are currently very basic, but later on this will be much nicer than manually calling `sl commit` a bunch.
This diff also splits our one integration test into two tests, so we have one test for commits and one for uncommitted changes.
Reviewed By: quark-zju
Differential Revision: D44280889
fbshipit-source-id: 06afa031e622753a51b28401e3f0da7e49a0bcfe
Summary: Small quality of life thing for integration tests, don't render all the server output and communication messages unless you run `yarn integration --verbose`.
Reviewed By: quark-zju
Differential Revision: D44279103
fbshipit-source-id: 22962f1a9c5733fee20ada11456c43515aa28f76
Summary:
Our tests right now are all unit tests, where the client has to mock responses from the server and the server can't tell if it's sending the messages the client actually understands.
Unit tests are great for mocking out specific scenarios, but we also want at least a handful of tests to validate that ISL can run on a real repository with real `sl` commands. This could catch a number of app-breaking bugs.
This diff adds the jest config / command to run integration tests, and a very simple first integration test that checks that commits appear in the UI and uncommitted changed files appear in the UI.
The idea is that we already run our UI tests in a node process with react-testing-library, which lets us fake render to a JSON "DOM" and then validate our UI DOM and click buttons and stuff. In that same node process, we can run `onClientConnection` to start and ISL server. We just need to hook the client code's messageBus up to our manually invoked `onClientConnection`, so that the client sends messages to the server. Little do they know it's all in the same process.
This is a very simple way to get integration tests to run, while also giving us all our normal react-testing-library UI assertions:
```
// inspect what was rendered
expect(screen.getByText('My Commit')).toBeInTheDocument();
// click buttons
fireEvent.click(screen.getByTestId('my-button'));
```
We can probably get fancier with our test repo, but right now it just runs `sl init --git .` to create an empty repo and adds a single file and commits it.
This all happens in a new repo per test run, so we should be able to run multiple integration tests in parallel. Multiple tests within one file would run in series.
Generally, I expect we'll still run most of our tests as unit tests, and use integration tests for specific complex workflows / scenarios that we want to make sure stay working, for example:
- basic commit rendering
- basic uncommitted changes
- writing commit messages
- handling merge conflicts
- interactive split / edit stack
Other things:
- Unfortunately, coverage doesn't seem to work outside the `<rootDir>` of the jest config, so we don't get coverage for the `isl-server` dir. Although we can get coverage information of the client.
- We could also do more end-to-end tests by spawning a standalone Tauri instance and doing tests with them and a real server. This would test the actual server<->client websocket code, but it may be harder to do assertions and more difficult to set up a test runner.
Reviewed By: muirdm, quark-zju
Differential Revision: D44184111
fbshipit-source-id: 164c36a6a7a741b3303236400d55b9a17cb8bede
Summary:
I would like to refer to some performance data of `gca` in the Segmented
Changelog doc.
Initially I was trying to make `drawdag` fast since it can use an elegant
syntax `A001..A999` and can work for both git and hg formats
(`debugexportrevlog` can be used to create repos that the upstream Mercurial
can understand). However it turns out to be a lot of work to make `drawdag`
"just" fast so I ended up writing dedicated scripts to create repos with
millions of commits.
Reviewed By: muirdm
Differential Revision: D43373717
fbshipit-source-id: 5ea1753027cb7487099ed00007e4cc0beae8a09a
Summary: I noticed that fetches for old commits were still sometimes failing, and I found that our revset was `smartlog() and date(-14) + .`, but we actually want `smartlog(date(-14) + .)` to calculate the smartlog from the set of recent heads and always include `.`. `smartlog(x)` is the better choice for us, since it automatically includes the ancestors of `x` in order to render the tree up to that point, which is exactly what we need.
Reviewed By: quark-zju
Differential Revision: D44276722
fbshipit-source-id: 6503471fb821dbc30d142ffbcbafb988652450cb
Summary: We added a diff button next to files when using vscode, so you can open a vscode diff view for a file. This doesn't make as much sense for merge conflicts, because the diff is not correct and the button makes it harder to find and click on the resolve conflict check button, which should be the most used one.
Reviewed By: quark-zju
Differential Revision: D44308276
fbshipit-source-id: 0663690774eb91cfd6896c83faecc6bf8a82b064
Summary:
If you check the "submit as draft" checkbox, we should remember your selection across restarts of the app.
To do this, we want to use `sl config` to get and set a config value. This way, we're using the same config system that the rest of sl uses, which is both easy to do and consistent.
I wrote a helper that wraps this sl config persistence for any recoil atom via a recoil effect. This will make it very reusable on any other bits of UI that we want to persist (e.g. changing how uncommitted changes are rendered or whatever)
Reviewed By: quark-zju
Differential Revision: D44278888
fbshipit-source-id: fe024fb3518e541212eb41b29c2c3007a43012ef
Summary:
Thanks to optimistic state, it's possible to queue up a submit for a specific commit. But using the hash would lead to trying to submit the obsolete commit when it gets succeeded by any operations before it in the queue.
We have a whole system for this, where we pass revset args in a special way to re-interpret them with a revset that skips past successors.
We've talked about changing this system a bit to track things more explicitly rather than just using `max(successors(${revset}))`, but for now this works ok, but we do need to be mindful to always pass revsets in this special way (that would be true even if we re-wrote this system to track successors manually)
This only applies for our internal submit flow, since ghstack and pr submit don't let you submit arbitrary commit hashes (you have to goto them first).
Also, for simplicity, we can remove the commit hash argument from submit when it's the head commit. This makes the command args simpler which is nice, and removes any issues around successions.
Reviewed By: quark-zju
Differential Revision: D44275963
fbshipit-source-id: 337837b1ef580711d2ba0495d21447a0678770d0
Summary:
Add a draft checkbox next to the submit button in the commit info view, which controls whether the diff will be submit as a draft or not.
This makes sense to live next to the submit button in the commit info, since commit & submit / amend & submit are probably the most common ways to submit.
We'll use an interstitial for the "submit stack" functionality, since there's not real-estate for the draft checkbox under every stack.
The draft functionality actually varies between internal and github review providers. You can only create draft PRs at creation time, but not at update (resubmit) time. So we defer to the codereviewprovider to know if we can resubmit as a draft or not.
Reviewed By: quark-zju
Differential Revision: D44275874
fbshipit-source-id: 8b3be677ccce8d1299227f525301428987f546b9
Summary:
Allow changing your currently selected commit via the up/down arrow keys. To do this, we leverage linearizedCommitHistory from the previous diff, and increment/decrement our index in that array to use as our selection. We also use `previouslySelectedCommit` as the commit to base our arrow key movement from, which feels very intuitive (as opposed to preventing arrow keys if you had multiple commits selected)
Also, if you hold shift and press arrow keys, we want you to be able to extend your selection up/down, as if you held shift and clicked each commit. This is useful to quickly select a whole stack, for example.
Reviewed By: quark-zju
Differential Revision: D44243957
fbshipit-source-id: e61339e35448e9bf557d0c4aedfb3c005b60e9cb
Summary:
If you hold the shift key and click on a commit, it should select from your previously selected commit up to the newly selected commit.
This should work across branches, according to the visual layout of commits
Reviewed By: quark-zju
Differential Revision: D44243956
fbshipit-source-id: d259bb0fed11d51d105ae9b375433166ad8545fc
Summary:
If you select a commit, you see it in the sidebar. Depending on your code review provider, you may be able to submit this commit without `goto`-ing there.
We should add the `submit` button to the sidebar for these cases. But we defer to the review provider whether it supports submitting individual commits. If not, we don't show the button.
This also allows review providers to refuse to submit certain commits, such as already landed diffs.
Reviewed By: quark-zju
Differential Revision: D44238646
fbshipit-source-id: 2ca508a90539a7465d967bda8ad702723ef5a1e4
Summary:
Add parameters to submitOperation API in UICodeReviewProvider so that you can submit as a draft or include an update message.
We still need the UI to be updated to show these options and actually pass them to our calls to submit.
Reviewed By: quark-zju
Differential Revision: D44238647
fbshipit-source-id: db99b49b50ee3d08f694db34e7b4c859bb3dfee2
Summary:
When multiple commits are selected, we show them in the sidebar to add bulk actions like submitting all selected commits.
When rendering commits like this, we don't want to include the "You are here" uncommitted changes area, or any buttons like goto and uncommit. Those actions just don't belong in this context.
Reviewed By: quark-zju
Differential Revision: D44235554
fbshipit-source-id: 1f80b78350f9457f5e66139599f57c61c46eddc7
Summary:
The previous diff added the abilty to bulk submit selected commits. This actually doesn't work for GitHub repos, so we should make this a code review provider gated feature.
Additionally, we don't want to let you submit closed diffs, so we can make our provider define which subset of selected commits is bulk-submittable.
Reviewed By: quark-zju
Differential Revision: D44118026
fbshipit-source-id: d90a2136dab0eeed2993243db379ef2553704251
