Summary:
This is the reversed direction of `debugexportstack`, to create commits from
automation. It also supports `goto` and `reset` to support partial commit
(commit, reset), absorb (commit*, reset), amend (commit*, goto) cases.
Reviewed By: muirdm
Differential Revision: D44231010
fbshipit-source-id: 03d2e5a7d577a2c6becb5e7d9f162fea191ad9af
Summary: Check that the test cases actually cover various logic in debugexportstack.
Reviewed By: zzl0
Differential Revision: D44231012
fbshipit-source-id: dbb24c7f87ecd11d23aae1707b68f77486177ef7
Summary:
This makes it easier to verify that a complex Python function is fully
exercised.
Reviewed By: zzl0
Differential Revision: D44231013
fbshipit-source-id: 6269dae56acff4f29a6aa5b7ad0ab89c33601ee1
Summary: Add debug info for edenapi configs to verify if it load the static_system configs correctly
Reviewed By: quark-zju
Differential Revision: D44298145
fbshipit-source-id: 96efb86c4e96a945b7329ae1e9cba3fdf57a5128
Summary:
During cross-repo pushrebases, we need to log new commits both in large and small repos. But currently, due to the code organization, it is not too hard to forget logging in the small repo. Which is what happened in case of SCS land_stack method.
This land path was not covered, and only large repo commits were logged. For example, this led to most public opsfiles commits being missing from the category (sync to opsfiles_backup uses different code path and exposes the discrepancy):
{F912075962}
(https://fburl.com/scuba/mononoke_new_commit/8q0nbq8i)
Reviewed By: markbt
Differential Revision: D44187074
fbshipit-source-id: bba2bf112fc9326ae5fc177d421ec936a2bb5322
Summary:
The environment is passed into the async runtime via an `Arc`. If the last reference to the environment is dropped from within the runtime, then we end up destroying the runtime from within the runtime, which is an error.
Move the runtime out of the environment, and store it in the `MononokeApp` (new) or on the stack in `main` (old). This means the runtime will live on the stack outside of the async runtime, and so execution of all async code should be complete when they are dropped.
Reviewed By: YousefSalama
Differential Revision: D44299775
fbshipit-source-id: 9a93ba49a8bbf376defdd0b5ddb1d6546b5ff12b
Summary:
Curently, `debugcrdump` returns an empty string for `branch` if there are multiple downstream remote bookmarks. This diff returns the first bookmark as the best guess, which should be the bookmark (commit) that the current local commit is based on.
Caveat: for multiple downstream bookmarks, it's a best effort guess, the algorithm is like:
1. For a given commit, find the first public ancestor.
2. For that ancestor commit, find all descendant commits that have remote
bookmarks sorted in ascending order.
3. If the descendant remote bookmarks contain "master", return that.
4. Otherwise report the first remote bookmark as the current branch. For draft commit,
this should be (best guess) the remote bookmark on which the draft commit was based
if user didn't run pull from remote server.
For example, if your commit graph looks like this, it will return `bookmark1` (first one) as the branch name, this is probably what you are expecting.
```
Y: public bookmark2
|
| a: draft (your local commit)
|/
X: public bookmark1
```
But if you run a `hg pull`, then the graph might look like below, it's impossible to know for certain which remote bookmark the local commit was made against. For now we also pick `bookmark1` as a guess.
```
Z: public bookmark2
|
|
Y: public bookmark1
|
| a: draft (your local commit)
|/
X: public
```
Related diff: D17814487, this was the diff that first added `branch` field.
Reviewed By: sggutier
Differential Revision: D44355664
fbshipit-source-id: b5287578d82c756f2d7035ae5ffa9a542ab957a0
Summary: this is for reproducing the issue of T148764976
Reviewed By: sggutier
Differential Revision: D44360807
fbshipit-source-id: 14400f9abc3ef6ca8e72d1c4a1f20b6ada6361fa
Summary:
This test has been flaky practically since its creation, although below the threshold to be detected as such some of the times.
Looking at its journal, it failed its first stress run and more than half
of the stress runs thereafter (failed 1920 of them, passed 1519 of them).
The assumption that the test makes that we will always take the local path first
is not stable and has never been.
Match the test's expectations to the actual behaviour of mononoke for now.
If the behaviour is problematic, let's tackle it in its own time.
Note that this test was written here D34276252 in reaction to a change to
segmented changelog here D34041066 and the discussion on that diff is relevant
to establish the correctness of the code.
Reviewed By: RajivTS
Differential Revision: D44297278
fbshipit-source-id: 07f42fc11ca0aa637b59b5fc46263b65d624e0a4
Summary: After enabling remote derivation we've lost related to derivation logging in the parent scuba table (like SCS server). This diffs add log tags, which indicates when we requested remoted derivation and when it was finished. In case of the error we already had the logging in place.
Reviewed By: Croohand
Differential Revision: D44297304
fbshipit-source-id: 1e2f6e279e111ce01b2feaf950a11c7b69a314cf
Summary: useful for checking if an object is in the hgcache or not
Reviewed By: quark-zju
Differential Revision: D44316641
fbshipit-source-id: f16093ec1659a8f139b88e702dbd1d8646319c8a
Summary: In the next diff, we'll use this util function to acquire an exclusive handle to a file for a prjfs integration test.
Reviewed By: xavierd
Differential Revision: D44349708
fbshipit-source-id: ded7037266f539c681569f0c90f875717760fed5
Summary: We are running into fileNotification() failures way more often than we expect on Sandcastle (5% of certain jobs are failing). Let's add some logging here to see if the failures are also happening to users.
Reviewed By: xavierd
Differential Revision: D44350819
fbshipit-source-id: 3be7578dccc297071280f528b53270a63994a99d
Summary:
DurationScope has a pair of atomic reference count operations at the
beginning and end of every recorded duration. To avoid that overhead,
reference EdenStats with RefPtr and, in production EdenFS, store a
global, unowned EdenStats object.
This gives us the benefits of explicit dependencies and no global
state in tests, while avoiding atomic RMWs in the release build.
Reviewed By: xavierd
Differential Revision: D44323723
fbshipit-source-id: 1b3384d2e6a0a2959fd79774a8ba46afc4c176ca
Summary:
In Rust 1.68.0, the `derivable_impls` clippy lint [got smarter](https://github.com/rust-lang/rust-clippy/pull/10161).
Fix all instances of that lint in Mononoke, mute one that's impractical to address.
Reviewed By: markbt
Differential Revision: D44378068
fbshipit-source-id: 473a051a7001d9596db43f47b56cbad5f5db7efe
Summary:
In Rust 1.68.0, the `useless_conversion` clippy lint [got smarter](https://github.com/rust-lang/rust-clippy/pull/10020).
Fix all instances of that lint in Mononoke.
Reviewed By: markbt
Differential Revision: D44378069
fbshipit-source-id: acfd6c77c6a400830c378b4040661323e7232441
Summary:
Original commit changeset: 8c2f66457761
Original Phabricator Diff: D44111246
This seems to be causing stdout ordering issues too, possibly because of PYTHONUNBUFFERED environment variable
Reviewed By: fanzeyi
Differential Revision: D44356269
fbshipit-source-id: 707495d785987308d9c4617a582ccb8613ed5016
Summary: If an EdenAPI request is taking too long, we currently have no signal into this until it either completes or is cancelled. As for wireproto, add logs for long-running requests.
Reviewed By: liubov-dmitrieva
Differential Revision: D44340299
fbshipit-source-id: e24bed96505964c519ea85748207670ded3baacb
Summary:
When streams are cancelled we lose all of their stats, as they only get logged after the stream is polled to completion.
Make the stream stats callback synchronous (we don't actually use its async nature), which means we can call it from a `Drop` implementation, allowing us to log the stats even when the stream is not completed.
To distinguish the two cases, we add a "completed" flag, which is true if the stream was polled to completion.
This also makes `completion_time` optional, as we don't have a value for this if the stream was never polled at all when it got dropped.
`TimedStream` had an implicit fuse-like nature (once completed the stream would never yield anything again), which we rely upon, so make sure this property is maintained.
Reviewed By: liubov-dmitrieva
Differential Revision: D44331959
fbshipit-source-id: 5a7d9875a4d7fd4276c304b6c30ff45c6b990b38
Summary: Version bump and changelog entry for new OSS vscode extension release
Reviewed By: quark-zju
Differential Revision: D44314900
fbshipit-source-id: b1e48ecfaa1735d60b3e7e7faaf0e1eec2dabd28
Summary:
As Croohand pointed out on D44183928, if the shared future is cancelled, the `WeakShared` will linger in the collection until the next read of that key. If the read of that key never comes, it will never be cleaned up.
Switch to a scopeguard, that we move into the future. This will execute the code to remove the shared future whether the future succeeds, fails, or is dropped.
Reviewed By: Croohand
Differential Revision: D44342772
fbshipit-source-id: 37fb15d126d8289d61ab33f64f6e1cf9f7a8550d
Summary:
In production we use Logger to log to Scribe (e.g. to "mononoke_new_commit" category). It has WhenceScribeLogged enum field which can be "default", "prod", "sandbox", etc.
Without override, Logger sets "default" value that usually resolves to "prod", **but** it resolves to "sandbox" if code is run from devserver. "sandbox" means we log data to "/sandbox" category instead of usual place.
This is confusing/harmful for us since we only configure to use Logger while working with prod data. For example, if we run SCS locally and land to prod using "land_stack", the commit will go to prod while logging will go to sandbox category. On the other hand, if we run Mononoke Bootstrap to work with a test repo, we don't use Logger at all so the "sandbox" category has no benefit.
We can add more complexity to the Mononoke logging configuration, so we are able to override WhenceScribeLogged in any way we want. But for now, I suggest overriding it in place with "prod" value since we only use Logger in prod. Later we can even simplify the config by removing the old way of logging directly to Scribe and leave just two options: test (log to file) and prod (log via Logger using the "prod" override).
Reviewed By: markbt
Differential Revision: D44118890
fbshipit-source-id: 8d4b9faa6f1f2da1faa96db35dd567102ccde34d
Summary:
We use interngraph GraphQL queries for a few things (phabricator diff info, scmquery log integration).
First, move the graphql endpoint config from static to dynamic config and vary it based on domain.
Finally, set x-x2pagentd-inject-cat in GraphQL request header when using x2pagentd. This replaces the oauth token mechanism, even for existing VPN/corp use. Note that the off-vpn endpoint rejects requests with both x-x2pagentd-inject-cat header and access_token in the body. We can delete the oauth stuff once we are confident in the x2pagent usage here.
Reviewed By: quark-zju
Differential Revision: D44317674
fbshipit-source-id: 329d63207fd9a5b19a145e12b491e270b5924571
Summary:
Send graphql queries over the local proxy socket, if configured. This is a prerequisite for off-VPN compatible access.
I added an escape hatch config phabricator.use-unix-socket we can use to disable this if someone breaks.
Also, kill apparently dead phabricator_graphql_client_requests.py.
Reviewed By: quark-zju
Differential Revision: D44317673
fbshipit-source-id: 52b58ce7899ce7291b700a9fe206da6011f740e5
Summary: Compare file mtimes so we synchronously regenerate dynamic config if the user has modified /etc/mercurial/vpnless. This way things will work off-VPN immediately after writing "1" to /etc/mercurial/vpnless.
Reviewed By: evangrayk
Differential Revision: D44263217
fbshipit-source-id: 1f09591336b7dc1294e1f21fafebce7962859d70
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
