[pull] main from facebook:main #633
Open
+161,958
−113,027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement derivation of case conflicts skeleton manifests for changes including subtree operations. For subtree copies, we can re-use the case conflict skeleton manifest of the source as it will be identical. Reviewed By: mitrandir77 Differential Revision: D66499862 fbshipit-source-id: f6468b13121c5b39548bf818fe4f114f446e4275
Summary: With subtree operations, it now becomes possible for pushrebase conflicts to occur at the root path. This is actually fairly unlikely, but it could happen if, for example, we are copying from the root of an old commit. Change conflict detection (and conflict errors) to use `MPath` instead of `NonRootMPath` so that the root directory can be included in the checks. Reviewed By: RajivTS Differential Revision: D66499859 fbshipit-source-id: 65a536242254d4333032d6b5bf79d81a4030c390
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** This diff implements support in pushrebase. There are a couple of steps: * Pushrebase must check for conflicts between subtree operations and other changes. A pushrebase conflict occurs if the destination path of a subtree copy overlaps any other path. They also occur for source paths *if* the source commit is part of the rebase set (as the contents will have changed), however they are *not* a conflict if the source commit is some other public commit, as the subtree copy source will continue to point at that original commit. * When pushrebasing subtree changes, we must adjust the source commit if it is part of the rebase set. Reviewed By: mitrandir77 Differential Revision: D66499861 fbshipit-source-id: cb6e9a407b553620e47176495a5cd08a2d0ee357
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** This diff implements derivation of mercurial changesets when subtree operations are used. For copy operations we must re-use the source mercurial manifest so that we match client behaviour. If copy operations are present then the list of changed files in the commit text is expected to be empty. Finally, we must generate an appropriate subtree commit extra for the subtree changes. Reviewed By: mitrandir77 Differential Revision: D66499858 fbshipit-source-id: c6a44595aff4fa9be88a7fb51457d77ead424315
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we add some more tests that allow us to test more complex scenarios, as well as test all derived data types as we implement support in them. Reviewed By: mitrandir77 Differential Revision: D66775637 fbshipit-source-id: 7d1d388f50b14df32059807bf616233f1af6ec47
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support for deriving unodes, deleted manifests, and fastlog with subtree operations. Unodes are required by design to be unique in the repository. This means we cannot take advantage of the subtree copy to do O(1) derivation. In the future we will replace unodes with a derived data type that understands subtree copies and won't have this restriction. Similarly, deleted manifests must ignore the subtree operation as they do not have support in their design for a different history. We base the deleted manifest on the unode tree so that the subtree operation is ignored. Reviewed By: zzl0 Differential Revision: D66775635 fbshipit-source-id: 1a93ad993dbeb412cb5ece903999bbb612369145
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** Unodes by design do not include copy information. Copy information is instead queried as unode rename sources. Generalize unode rename sources to include other types of rename source, and add subtree copies and merges as rename sources. Reviewed By: andreacampi Differential Revision: D66775636 fbshipit-source-id: 0ffb7e8a459f8af80154b31b8a169a82a17f9e60
Summary: Some of the blame type are confusingly named. Clean up the names before we introduce new ones. After this change: * A `BlameRange` is a range of lines with the same blame info. * A `BlameRangeIndex` is the same thing but using indexes for data like paths and changeset ids. * A `BlameRangeParentIndex` is the parent information for a blame range, again using indexes. * A `BlameLine` is a single line's blame info. * A `BlameLineParent` is the parent information for that blame line. Reviewed By: zzl0 Differential Revision: D67087918 fbshipit-source-id: a4efc46aa704b1a9e97bbe8f1beb5645e7cf881d
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we add support for deriving blame for files that have been copied or merged via subtree copy or merge. This introduces a slight change to the blame API for parents of changes. Previously, parents would always be a real parent of the blamed changeset, so we could provide the parent index. Now it is possible for a parent to be the subtree copy source. We call these parents "replacement parents" and provide the full hash in this case. This fact was already true for mutable blame, and was one of the ways in which mutable blame was incorrect. We can now use this feature for mutable blame also. Reviewed By: mitrandir77 Differential Revision: D66775638 fbshipit-source-id: 023a8099b5d4de8976d9e0692524eec0793d1214
Summary: When mutable blames are being generated, we used to lie about the parent index as there was no way to list the mutable blame source as a replacement parent. Now that subtree operations have added that capability, make use of it to give more accurate mutable-history blames as well. Reviewed By: andreacampi Differential Revision: D68736391 fbshipit-source-id: 2d7871560b30cb0de3d6dcd6348c806e36da8efe
Summary: Derivation of single changesets within a batch may need to know about other commits from earlier in the batch if they include subtree copies from those commits. Add a `known` parameter to `BonsaiDerivable::derive_single` to allow for this. Reviewed By: andreacampi Differential Revision: D66960069 fbshipit-source-id: b8a3a75b486c202bedf1a47daac19891ca68fe36
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we add support for deriving skeleton manifests (v1 and v2) for commits that contain subtree operations. Reviewed By: andreacampi Differential Revision: D66837800 fbshipit-source-id: 3a25d7062e651ca00bbd7167c8362582dc72530d
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support for deriving bssm3 for commits that contain subtree operations. Because of the nature of basename suffix skeleton manifests, there is no efficiency advantage when deriving them for subtree operations, so we must expand the subtree operation out to its full changes in order to use the existing code path to update the bssm. Reviewed By: andreacampi Differential Revision: D66837799 fbshipit-source-id: 122df67c8a9a3e8b45f2e4d59279adc2af06b9db
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support in test manifests (which are only used in tests). Reviewed By: andreacampi Differential Revision: D66837795 fbshipit-source-id: 84f512d6925c30db787dee74f9602277c3eba2cb
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support in test manifests (which are only used in tests). Reviewed By: andreacampi Differential Revision: D66837798 fbshipit-source-id: e44110d8fec372e1ef2b5275a052bfe062ae65c6
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support in fsnodes. Since fsnodes are purely content-addressed, we can trivially re-use the source fsnode for copies. Reviewed By: andreacampi Differential Revision: D66837801 fbshipit-source-id: 1cc33e146488e26ce6060e6aa9b68b0e412f7f17
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support when deriving Git tree types. This is not likely to be used any time soon, but since git trees are purely content addressed it is simple to do. Reviewed By: RajivTS Differential Revision: D66973014 fbshipit-source-id: 6148bb620d688eeccc2b0cf7aae2cc728cdeb786
Summary: **Introduce subtree operations to provide server-side support for efficient directory branching.** In this diff we implement support in content manifests. Similar to fsnodes, these are able to re-use source trees. Differential Revision: D66837797 fbshipit-source-id: 81f9feb3a62563c330197cfcad07a7291c89dfa7
Summary: The complex commit graph queries have a large common part that is used to fetch all of the identified edge data. Extract this to a macro so we can change it more easily. Differential Revision: D68420964 fbshipit-source-id: 085a4b058ef76ba929225f7b3111dfef46beed81
Summary: Subtree operations (copies or merges) create a new kind of edge between commits. For most commit graph operations these can be ignored, and this is what maintains the simplicity of the commit graph for most uses. However, for derived data, we *do* potentially need the subtree source to be derived. This means commit graph traversals for data derivation need to take subtree sources into account. Most of the time, the subtree source is an ancestor or public commit, which means it will usually be the case that the data is already derived anyway. The exception to this will be in backfilling processes, which need to take into account the whole shape of the graph. To allow this, extend the commit graph to include additional edges for subtree sources. Most of the time these will be ignored. We will only use them for data derivation. In this diff we add the defintion of subtree source edges and add them to the calculation process. They are not yet used. Reviewed By: andreacampi Differential Revision: D68420963 fbshipit-source-id: 183ee849c5d3a415c06d3f5f7c68ef51c0926224
Summary: We are going to need things that are not in `BasicTestRepo` for future hooks tests. Simplify this by creating a `HookTestRepo` to use in tests. Differential Revision: D68779499 fbshipit-source-id: 13f553159fd8a84c0b1ffbcb39666916a83d7f2e
Summary: We are not planning to implement full handling of subtree copies for paths that are being synced between small and large repos in the megarepo infra. This is tricky to do, as there is no guarantee that there is a suitable corresponding copy source in the target repo for the sync. Instead, prevent these from being landed with a hook. We can work around this issue for copies that need it by using a deep copy instead. In the future we may implement support, at which point this restriction can be relaxed. Reviewed By: andreacampi Differential Revision: D68705199 fbshipit-source-id: 13cd500eae820092dbecbf42a9b76b3edc3ab9bd
…anifest Summary: When rewriting commits, we can accept rewrites of commits that include subtree operations as long as a subtree copy that re-uses the source tree isn't present. We need to use a deep copy instead for these locations so that the commit transformation can work. When we do these transformations, the subtree copy or merge information is lost, as we cannot guarantee that there is a corresponding source location for the subtree operation in the destination repository (e.g. the directory could have been copied from outside the small repo's area). We deliberately remove the subtree metadata and mark the commit as created via lossy transformation. Reviewed By: andreacampi Differential Revision: D68706269 fbshipit-source-id: a8ae0e78374ef63b7e677b8e4a20ef4e2658f613
Summary: There are multiple internal and external "object not found" reports. Port the D57414984 hotfix. Unfortunately this effectively disables git gc for now. But otherwise the "object not found" errors are even worse. Reviewed By: zzl0 Differential Revision: D69683415 fbshipit-source-id: b4c6cc85bbf3f227350e8d984b1ffad7d95c2732
Summary: Git modules spec (https://git-scm.com/docs/gitmodules) says the relative url should be treated as relative to the origin url. We don't support it yet. Add a test to track the support. Reviewed By: zzl0 Differential Revision: D69683542 fbshipit-source-id: 6f43b3293d71c722d8021fd468a5194d6b8d5370
Summary: GitHub commits: facebook/buck2-prelude@3f752d6 facebook/facebook-for-woocommerce@08cb559 facebook/fb303@b7ad881 facebook/fbthrift@18a3523 facebook/folly@b569023 facebook/mvfst@b306c18 facebook/proxygen@d25e573 facebook/wangle@c942fa7 facebookexperimental/edencommon@b0184e7 facebookexperimental/rust-shed@4452436 facebookincubator/Facebook-Pixel-for-Wordpress@e6473ee facebookincubator/fizz@849a8a6 facebookincubator/llm_orchestrator@a647d88 facebookresearch/mvdust3r@430ca66 Reviewed By: bigfootjon fbshipit-source-id: da137a94931673f462d7f6ff8d9a24e51f907339
Summary: I think it can be helpful in cases like [this one](https://fb.workplace.com/groups/mercurialusers/permalink/3003212986494228/) and heads will still be in the workspace history Reviewed By: markbt Differential Revision: D69723176 fbshipit-source-id: 13e6a14b1e589ef231391f7b32e1f48bb7784352
Summary: The revisions omitted due to the skip option are of less interest to users. This diffs differentiate between "skipped" and "non-skipped" commits in the bisect result. Reviewed By: quark-zju Differential Revision: D69757046 fbshipit-source-id: e9f99cc68f19372ec3db7c26f040aeea2180a6fe
Summary: `summary` is deprecated, its information is coverd by `sl sl` and `sl status` Reviewed By: MichaelCuevas Differential Revision: D69757045 fbshipit-source-id: 83022970935f38f62926d736080f65f96971a294
Summary: # Context We’ve encountered issues in the past of certain functions having wide execution fan-out, meaning one Thrift call could tie up all of the Thrift CPU threads to serve the request. This is not ideal, as this results in other clients receiving `QueueTimeout`s due to waiting too long to get Thrift requests picked up for execution. We’ve combated this in the past by limiting some Thrift entry points to serial execution. This has become a game of whack-a-mole with new instances of `QueueTimeout`s, requiring copying this logic to different functions that seem to have similar fan-out, and is error prone since its easy to forget to set up a SerialExecutor while refactoring pre-existing functions. There are some mission critical entry points that are known to be more heavyweight and should not be executed serially. There are a few options to be explored for these cases, including adding thread pools for particular heavyweight entry points, or implementing a Executor which can use smarter internal load balancing, such as a token bucket backed solution. This diff explores the first option. # This Diff This diff adds a `UnboundedQueueExecutor` that can be used to drive `checkout()`. Without this, and while using serial execution for Thrift requests across the board, checkout becomes too slow. This allows us to use serial execution for everything while keeping `checkoutRevision` performant. We might need to introduce similar executors for other endpoints, TBD. # Technical Details The use of a `UnboundedQueueExecutor` is explicit here. I plan to go through and remove uses of bounded executors in EdenFS. It is not recommended to use bounded executors with async code [1] # Facebook [1] - https://fb.workplace.com/groups/474291069286180/posts/5360947373953834/?comment_id=5361092820605956 [Threadpool Project Plan](https://docs.google.com/document/d/1yvYFYk8UT3hW9M7Qw-NSIpvqYFUxjHL8FhM81cYQGeQ/edit?tab=t.0) Reviewed By: jdelliot Differential Revision: D70135765 fbshipit-source-id: 66634542dbc3c69e8bb2c75ab071313e0ab37f80
Summary: follow wiki (https://www.internalfb.com/wiki/Rust/Third_Party_Libraries/Adding_or_Updating_Libraries/#maintaining-local-change) to patch the pkg w/ my PR. * rust-vmm/vm-allocator#95 * Added a `used()` API in `AddressAllocator` so in runtime we can report DRAM/SRAM usage. NOTE to myself on updating rust 3rd party lib * update https://www.internalfb.com/code/fbsource/[eae01930e4f97fad5f6f03341bbbdc0b62636187]/third-party/rust/Cargo.toml?lines=1483 * `cd ~/fbsource && fbcode/common/rust/tools/reindeer/vendor && arc autocargo` Reviewed By: diliop Differential Revision: D69826054 fbshipit-source-id: c712d57a6e74398b61e8288c6fae5d50954a967f
Differential Revision: D70244067 fbshipit-source-id: 06262d7b5cd8bf1643e29e22bef45eb33a609c32
Summary: The redirection API [`list_effective_redirs_for_mount`](https://www.internalfb.com/code/fbsource/[0a9e4dc34705]/fbcode/eden/fs/cli_rs/edenfs-client/src/redirect.rs?lines=1174-1193) needs an `EdenFsInstance` to work. However, the `EdenFsInstance` is only available when the call is from the CLI, since the instance only gets initialized in the [MainCommand](https://www.internalfb.com/code/fbsource/[0a9e4dc34705]/fbcode/eden/fs/cli_rs/edenfs-commands/src/lib.rs?lines=231-235). To enable its callability via thrift & ffi, this diff * lets `list_effective_redirs_for_mount` take in an instance rather than create one on its own * enables the ffi method `list_redirections` to build an instance for calling the redirection API Reviewed By: MichaelCuevas Differential Revision: D70132721 fbshipit-source-id: 2491d0b4c745054bf12208e705c6fd130cbcabe6
Summary: benchu-meta called out an issue with `eden doctor` where it was hanging on some machines. Looking at one example, it was hanging because `watchman watch-list` was hanging. We can mitigate this by adding a timeout to the calls in `check_watchman.py`. Reviewed By: benchu-meta Differential Revision: D70205775 fbshipit-source-id: 027028b9cf1d4cf702b165851409cd6fff6d273b
…sues Summary: Capturing health-report detected issues and issue count as part of edenfs_events scuba table Differential Revision: D70266298 fbshipit-source-id: d6f1467db3c05c1a5eacde80b46b0b5490f0edad
Summary: I had this draft for a while but it caused some overwhelming on the remote end. After todays discussion let's try it out and see if we can make AWS support the load Reviewed By: RajivTS Differential Revision: D70249179 fbshipit-source-id: 0106329e0522fdc0e5f9e8559d90900387dcf7b1
Summary: WTTS Reviewed By: andreacampi Differential Revision: D70250488 fbshipit-source-id: 6e8edaa9ffd7c436f9fc1e41e57f284aa1bb1b2c
Summary: Currently we have negative "queue age": https://fburl.com/canvas/9pkw3sl3 This is my blind guess and I have no idea how to validate it -- we stored "now" in a local var, then went to query stats. In between these, there might be something else adding a new request to the queue with a later timestamp than "now", resulting in negative "age"? Reviewed By: andreacampi, RajivTS Differential Revision: D70246945 fbshipit-source-id: 4e9432cb200d6bebe854730b34ebdce3507d7641
Summary: ## This stack We are getting [repo stats](https://fburl.com/canvas/711bkpep) in prod but not in AWS. Let's fix that. ## This diff D69375419 started the stats loop only for the sharded case. Let's do the same when running unsharded. Reviewed By: lmvasquezg Differential Revision: D70317345 fbshipit-source-id: 29fb52fac3c4eb97e3e22f9c2f20a80ca0264552
…on-monotonic committer dates Summary: When performing a time-based shallow clone (or fetch), Git does a best effort clone of the commits if the repo contains commits with their committer dates not in monotonic ordering (i.e. earlier commits do not have a strictly lesser committer date than later commits). This integration test highlights this behavior and serves as a proof that time-based shallow clones work only for the commits with monontonic committer dates. This would be useful for Mononoke Git cause we can assume that the graph only consists of such commits. Differential Revision: D70242468 fbshipit-source-id: 6bf1a426fea13e35d0422cbd0804c987f687f4ce
Summary: We need this method to support time based shallow clones in Mononoke Reviewed By: mitrandir77, YousefSalama Differential Revision: D70181991 fbshipit-source-id: 80de21926780e56351067a9e3e30975158cec93b
Summary: We were missing this feature as compared to vanilla Git and this diff makes the necessary changes to support it. I will be adding more integration tests to validate time based shallow clone works as expected in all edge cases. Reviewed By: mitrandir77 Differential Revision: D70192305 fbshipit-source-id: f6d5e4cc105a50e118e2fbb775dab143f0d8f762
…Mononoke Git Summary: I planned on creating this integration test to highlight that shallow-exclude is a shallow variant that is not yet supported in Mononoke, but during the course of its creation I realized that even vanilla git's support for shallow exclude is broken. I have linked a paste in the test that shows how git's actual behavior varies from what the documentation indicates. Due to broken support in vanilla git, the integration test will compare the output of direct git command on the origin repo (`git rev-list --all --not branch_name`) instead of shallow-exclude clone using vanilla Git. Differential Revision: D70256943 fbshipit-source-id: 7291f27d85c600dc33cd9ceca1d3bf55de327e19
Summary: Currently, if someone sends a `shallow-exclude` clone or fetch request to Mononoke Git, we just error out with HTTP 400 status without any meaningful message. This diff makes the necessary changes so that we gracefully fail in such a case. Differential Revision: D70258186 fbshipit-source-id: 411facf776b8bf1731fdd28a152da55a7d4c06c2
Summary: We already log this in the edenapi sender Reviewed By: YousefSalama Differential Revision: D70325172 fbshipit-source-id: 07fc0d79bed87a33418c9e3a3e99f25a4821b7c1
Summary: GitHub commits: facebook/buck2-prelude@4adfc8a facebook/facebook-for-woocommerce@9c06d5c facebook/fb303@dd5fa64 facebook/fbthrift@fa877f5 facebook/folly@48940bb facebook/mvfst@bfdd58c facebook/proxygen@5fe1807 facebook/wangle@48ba01e facebookexperimental/edencommon@63ad39b facebookexperimental/rust-shed@f91130c facebookincubator/fizz@0634ab9 facebookincubator/llm_orchestrator@90516fb facebookresearch/mvdust3r@f10afc8 Reviewed By: JurjenLelifeld fbshipit-source-id: daf1dd51e1bdc69f0fcc2e74cef74d287b3a2170
Summary: enable force sync for public commits, without prior lookups there will be no prior find-missing checks, so we should be safe on TTLs. We can follow up after Conditional Writes. Reviewed By: lmvasquezg Differential Revision: D70334013 fbshipit-source-id: cea27831ddccfd0e4afe0386407a20a2c8654bb3
Reviewed By: mzlee Differential Revision: D70191157 fbshipit-source-id: d68a7d28be0a868b88eb71d43829cc4aacad975f
Summary: D69961508 add NFS error counters, and now we can have ODS counter for ESTALE error on NFS. However, scuba logger can help us to run more specific query and see how many hosts are affected by ESTALE err. Also, we are going to implement GC for NFS and gradually open it for users. It is a good indicator to know how many ESTALE errors are thrown on NFS machines before and after GC. For more context on ESTALE error see the summary of D30144898 Reviewed By: MichaelCuevas Differential Revision: D69991036 fbshipit-source-id: 7bc1703ef0722b2fcc6e74806ae84eb4e49db086
Summary: Problem Statement Laptop users frequently experience interruptions due to shutdowns and reboots, which can lead to unexpected issues with EdenFS. This can cause frustration when Eden is not ready to use after a restart. Solution To address this issue, we propose implementing a notification system that alerts users when EdenFS is ready to use after a restart or shutdown. This feature will be initially implemented on Windows systems. Reviewed By: genevievehelsel Differential Revision: D69509853 fbshipit-source-id: 3a8804b2c46cf404af5e9dd27ebb02f046588b89
Summary: X-link: facebookincubator/zstrong#1211 * Seems like rust-script is picky with the comment format for cargo dependencies. Switching from /* */ to //! allows is to correctly build the script. * Remove Ubuntu 20.04 (gcc too old) * Add Ubuntu 24.04 (latest LTS) * Remove Fedora 36/37/38 (38 support ended 2024-05-21) * Add Fedora 40/41/42 (42 to be released 2025-04-22) X-link: facebook/watchman#1275 Reviewed By: chadaustin Differential Revision: D70350468 fbshipit-source-id: f5a29743da5b381fadeba2ed35a440b4054ca453
Summary: # This diff Adds some telemetry to track how often inode loading fails on macOS due to X2P errors Reviewed By: genevievehelsel Differential Revision: D70353537 fbshipit-source-id: 0e1857308d7ad79e41673f23fae7ecabcd829e37
Summary: This diff * implements listRedirections * adds `ffi.cpp` and `ffi.h` into `eden/rust/redirect_ffi` for FFI -> C++/Thrift conversion. * updates integration tests to cover the thrift endpoint Reviewed By: MichaelCuevas Differential Revision: D70109432 fbshipit-source-id: a28219e2bfaa2752e23ca2215d51d0f1cbfa63fd
Summary: On D70109432, genevievehelsel pointed out cxx was able to declare shared enums in C++ [with static assertions](https://cxx.rs/shared.html#extern-enums). * This enables us to directly links up redirection enums defined in Rust and those defined in thrift/C++, without introducing intermediate representations `[EnumName]FFI`. * It further allows us to remove some boilerplate type conversion code in C++. Reviewed By: MichaelCuevas Differential Revision: D70343746 fbshipit-source-id: 7c5d0e356e26ad8e6fa467de7f15bc866ffa61a3
Summary: Fix perf regression by going back to unbounded queues (which don't pre-allocate space). Recently I changed various queues to be bounded to they wouldn't slurp too much stuff into memory (and provide backpressure all the way to HTTP fetches). I gave the queues fairly large limits to be conservative. Unfortunately the crossbeam::channel::unbounded(SIZE) constructor pre-allocates SIZE slots, so if SIZE is large, it performs large allocations (and is very slow). Reviewed By: jdelliot Differential Revision: D70366746 fbshipit-source-id: 09dd0afe8f5fab5088bc64dba1fcdf7b681db9cc
Summary: # Context The goal is to productionize the new **Performance** top-line metric for Source Control called User's Slowest Command (USC). Details and principles on the top-line metric design and development are in this notebook - N6350927. # Sequencing We have to present the first version of this metric on **2025-Mar-5 OKR review**. For that milestone we aim to build a dashboard, which will likely need. 1. Turn the notebook into a Python library so that it can be used both in notebooks and data pipelines. 1. Dedicated data pipeline as the `dev_command_timers` query is data and compute intensive. 1. Dashboard containing the top-line. 1. Sliced views by OS and which commands are contributing to the top-line. After the dashboard. 1. Integrate the metric into Deltoid so that it shows up in DevInfra experiments and gradual rollouts. 1. Integrate in SLICK # This diff Abstract the SQL query into a data fetching function. Reviewed By: MichaelCuevas Differential Revision: D70337568 fbshipit-source-id: 153beb569677d2dd8ee4c8969b743523c156f2dd
Summary: This client works for the hg-sync based CAS sync but using mononoke app it's a bit harder to comply with the lifetimes of this, and given we need them for CoreContext and/or the reponame, seems fine to remove them. Reviewed By: YousefSalama Differential Revision: D70322043 fbshipit-source-id: 4ce62cda3cfcc3221f99caf7f27ca51db28d114c
Summary: WTTS Reviewed By: YousefSalama Differential Revision: D70331944 fbshipit-source-id: cdf89e50005b5c09d174727388ddc5d53873b03d
Summary: initial content about augmented manifests Created from CodeHub with https://fburl.com/edit-in-codehub Reviewed By: lmvasquezg Differential Revision: D70387989 fbshipit-source-id: 15d17d453e9cc6fbd844c0e6612fb4a83724bfdf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )