Summary:
D21316793 is blocked from landing because there are a few targets in eden that are running pyre via buck targets integration.
We can't do custom version overrides for projects that are using a mix of local configurations and buck integration, because buck doesn't provide an interface for setting the equivalent pyre version override.
We're moving away from buck targets integration for pyre across the board, and I've run a codemod over the project to clean up all of the buck typing integration (including some residual mypy) as well as updated type ignores / fixmes accordingly.
Let me know if you have any concerns; upon skimming it looks like most changes are either converting `type: ignore`s into fixmes, or removing `type: ignores`.
Reviewed By: dkgi
Differential Revision: D21343093
fbshipit-source-id: 5ee1436377eb526c0a679fb821c42e07cbca52a5
Summary:
When running Eden as a service, CreateProcess will pop up a console window for every new console based process. Eden fs spawns hg import helper process which will create console windows. It doesn't impact the functionality but is a bad user experience.
Passing the CREATE_NO_WINDOW flag to CreatePeocess will suppress the console Window.
Reviewed By: wez
Differential Revision: D21361412
fbshipit-source-id: 96ecfa2d9ca811287cdc60ba1c4632f16f38340e
Summary: This enables the Edenfs to run as a console application.
Reviewed By: wez
Differential Revision: D21241794
fbshipit-source-id: 704e8488b680ac90f11e9eabef704879a395d7e0
Summary: By default the Eden on Windows will run as a service. It should be installed as a Windows service by the installer to work properly.
Reviewed By: wez
Differential Revision: D21241597
fbshipit-source-id: 2bcbd518d274d829bee5616d266c542f3fcc4b16
Summary:
ConEmu tries to normalize 256 colors to 16 colors but its normalization logic
is buggy. For example, color196 gets normalized to green instead of red. See
the attached picture of ConEmu and its debug real console.
{F235735030}
Reviewed By: markbt, ikostia
Differential Revision: D21311443
fbshipit-source-id: cb6db07d6b10a7365e33f4aa8f5f3f61f90c8e69
Summary:
While EdenFS does not use a separate privhelper process on Windows, it still
defines a stub PrivHelper class. However, this class was previously defined
in a separate win/utils/Stub.h header file, which led to awkward `#ifdef`s to
include the correct platform-specific header file.
This diff moves the definition of the dummy PrivHelper class in Windows into
the same `PrivHelper.h` header file used on POSIX platforms. This results in
a few more `ifdef`s in the PrivHelper files, but fewer `ifdef`s in the calling
code, and will make it easier to start unifying more of the `EdenMain` logic
on Windows and non-Windows platforms.
Reviewed By: xavierd
Differential Revision: D21332568
fbshipit-source-id: c63bf2b4a8b7e767d7db7dcda28675f735c23bf8
Summary:
The kernel has some legacy logic to attempt to clear the setuid and
setgid mode bits upon writes, but it is racy and disabled by default
in libfuse3. Now that we don't support setgid and setuid bits at all,
opt out of the legacy kernel behavior.
Reviewed By: wez
Differential Revision: D21334075
fbshipit-source-id: bdef12c1958a5e9bd2649c2bcb54975b0b4e78d6
Summary:
We'll be adding a bunch of Facebook specific configuration and values
here. Let's move it to someplace not open source.
Reviewed By: quark-zju
Differential Revision: D21241038
fbshipit-source-id: 2ac9cdce40b1b46f15f171d9d1f6b6692dcd29bf
Summary:
Implements an ensure_location_supersets function who's goal is to
verify that a given config location specifies the exact same configs as a given
set of other locations. Any inconsistencies are removed from the config and
reported to the caller.
This will be used to ensure our dynamic configs match our existing rc file
configs exactly, before we delete the file configs.
Reviewed By: quark-zju
Differential Revision: D21240837
fbshipit-source-id: e2c8ec054a3696d2cf02e65c212ad886c5117253
Summary:
The `parents` template currently returns "meaningfulparents". This sometimes
returns the null revision as the second parent, making templates think this is a
merge commit when it is not. Make sure we filter this out.
Reviewed By: quark-zju
Differential Revision: D21347776
fbshipit-source-id: af83fd5cff381850ac39d97b5b2f4c77033fe2fb
Summary:
Make all the things that only Lua hooks needed (hook type etc) optional.
With this done, configs can be cleaned up to not contain redundant data.
Reviewed By: ikostia
Differential Revision: D21349614
fbshipit-source-id: 1c72c2082b8c002e3feb41d1d720a41d21afaae5
Summary:
In the initial stages of the windows port we had
problems building rocksdb on windows, so we disabled it.
These days we're able to build it and detect it--we even
require it in the cmake code, but hadn't gotten around
to telling the rest of the code that we can use it.
This commit re-enables it in the build but leaves sqlite
as the default engine until we're able to perform some
benchmarking.
Rocksdb itself has some build issues on Windows; it doesn't
use cmake to locate dependencies, so even though we built
snappy it doesn't know how to find it without modifying the
source:
https://github.com/facebook/rocksdb/blob/master/thirdparty.inc#L4
For that reason, we disable the use of Snappy in the Windows build.
However, in the version of rocksdb that we were using, it would
default to trying to use Snappy even though it wasn't compiled in
and throw an exception.
I've upgraded to a newer version of rocksdb that will simply not
use compression if no compression was enabled at build time.
Given that we mostly store relatively small objects, I'm assuming
that the lack of compression is fine for now.
Reviewed By: xavierd
Differential Revision: D21319896
fbshipit-source-id: 2a2d06d4bd5382706e9220f9b4a2de99dc18311d
Summary: `cargo autocargo` should normally produce no changes on `master`. The features of the `log` crate was updated in D21303891 without re-running autocargo. This fixes it.
Reviewed By: dtolnay
Differential Revision: D21349799
fbshipit-source-id: ce487bc5989e179673297350249593103b4d34dd
Summary:
Now we download files in 200K chunks, and it might be confusing - it's unclear
whether hg is making any progress or not.
This diff makes it clearer.
Note I'm not printing progress before first fetch to avoid breaking the tests
Reviewed By: farnz
Differential Revision: D21348756
fbshipit-source-id: 05e5169114adf2b99a74b37d933755a644214a42
Summary: Mercurial Infinitepush normally records received bundles into the `forwardfillerqueue`, which is later tailed by the commit cloud `forwardfiller` in order be replayed onto Mononoke. Now I am adding a reverse filler, which means that we will have two such queues and sync in two directions. Therefore, in order to avoid infinite loops we need to distinguish cross-backend bundle replay from genuine pushes. I propose to use `crossbackendsync` bundle2 param to indicate that no recording is needed.
Reviewed By: krallin
Differential Revision: D21255446
fbshipit-source-id: 70f6efe1331bd3c7fd3aca61d486d350d93086dc
Summary:
Previously we weren't showing help at all when running "hg cloud --help". This
diff should fix it
Reviewed By: ikostia
Differential Revision: D21347825
fbshipit-source-id: 1d9d11e2f9fe18a03b5d2cd8bd316fe9a218347c
Summary: Let's make it tunable, more context in D21300885
Reviewed By: ikostia, krallin
Differential Revision: D21347636
fbshipit-source-id: 4bc91effdd212a3f5c4a0c3d4952f52a1cf417d7
Summary:
Path elements longer than 255 bytes cannot be materialized on most filesystems,
so allowing them isn't very useful.
We can't normally receive a push for this (because the client would have to
have the file on their isk), but they could get created through a
specially-crafted bundle or accidentally through a Thrift API (e.g. create
commit in SCS).
Reviewed By: farnz
Differential Revision: D21328145
fbshipit-source-id: cb32d6df0aa60863665a651f1a33c69c75c6a880
Summary:
In vs-code if you have a well-formed url you can command-click it
to open it, e.g., when you see it in your terminal. But this URL is not
well-formed because it's missing the protocol. So let's add it.
Reviewed By: quark-zju
Differential Revision: D21336742
fbshipit-source-id: dd2de2d5177d3a2542c4a22f0099f28b97c79d06
Summary:
Update the Windows code to use the normal StartupLogger.h and .cpp files.
Previously the Windows code defined its own separate StartupLogger.h file.
The class declaration looked largely like a copy of the POSIX
DaemonStartupLogger code, but most of the methods were not actually defined
anywhere. The actual functionality appears identical to the POSIX
ForegroundStartupLogger, so this code just switches to using that in most
cases.
Reviewed By: xavierd
Differential Revision: D21332570
fbshipit-source-id: 0585a38d8f37dc93459d380aa277082c35cbadfc
Summary:
Currently, Mononoke's configs are loaded at startup and only refreshed
during restart. There are some exceptions to this, including throttling limits.
Other Mononoke services (such as the LFS server) have their own implementations
of hot reloadable configs, however there isn't a universally agreed upon method.
Static configs makes it hard to roll out features gradually and safely. If a
bad config option is enabled, it can't be rectified until the entire tier is
restarted. However, Mononoke's code is structured with static configs in mind
and doesn't support hot reloading. Changing this would require a lot of work
(imagine trying to swap out blobstore configs during run time) and wouldn't
necessarily provide much benefit.
Instead, add a subset of hot reloadable configs called tunables. Tunables are
accessible from anywhere in the code and are cheap to read as they only require
reading an atomic value. This means that they can be used even in hot code
paths.
Currently tunables support reloading boolean values and i64s. In the future,
I'd like to expand tunables to include more functionality, such as a rollout
percentage.
The `--tunables-config` flag points to a configerator spec that exports a
Tunables thrift struct. This allows differents tiers and Mononoke services to
have their own tunables. If this isn't provided, `MononokeTunables::default()`
will be used.
This diff adds a proc_macro that will generate the relevant `get` and `update`
methods for the fields added to a struct which derives `Tunables`. This struct is
then stored in a `once_cell` and can be accessed using `tunables::tunables()`.
To add a new tunable, add a field to the `MononokeTunables` struct that is of
type `AtomicBool` or `AtomicI64`. Update the relevant tunables configerator
config to include your new field, with the exact same name.
Removing a tunable from `MononokeTunables` is fine, as is removing a tunable
from configerator.
If the `--tunables-config` path isn't passed, then a default tunables config
located at `scm/mononoke/tunables/default` will be loaded. There is also the
`--disable-tunables` flag that won't load anything from configerator, it
will instead use the `Tunable` struct's `default()` method to initialise it.
This is useful in integration tests.
Reviewed By: StanislavGlebik
Differential Revision: D21177252
fbshipit-source-id: 02a93c1ceee99066019b23d81ea308e4c565d371
Summary:
FUSE_HANDLE_KILLPRIV expects that any write() call is handled by
clearing the setuid and setgid bits in the userspace. To avoid
implementing that behavior, disallow setting setuid or setgid in the
first place.
Reviewed By: xavierd
Differential Revision: D21333703
fbshipit-source-id: eb084ee8b00afe74c0da26e41c32c2cb742723da
Summary: I'm about to add a new parameter to `scribe_commit_queue`; first asyncify it to modernise
Reviewed By: krallin
Differential Revision: D21288044
fbshipit-source-id: d1a4bb052b3c055383dd9d9df5fe36d61b14bdfe
Summary: If the bundle file has 1G in size, we probably don't want to waste 1G of memory just to see that it is too big.
Reviewed By: markbt
Differential Revision: D21177359
fbshipit-source-id: 026b5ab40e6dbddba3d7142a8e34256d127bf82c
Summary:
Building on the previous two commits, this adds a test which performs the following steps:
- does an infintiepush push to a Mercurial server
- looks into the `forwardfillerqueue`
- runs commitcloud forwardfiller's `fill-one` to replay the bundle to Mononoke
- verifies that this action causes the commit to appear in Mononoke
As this test uses `getdb.sh` from Mercurial test suite, it needs to be whitelisted from network blackholing (Note: we whitelist mononoke tests, which run with `--mysql` automatically, but this one is different, so we need to add it manually. See bottom diff of the stack for why we don't use `--mysql` and ephemeral shards here).
Reviewed By: krallin
Differential Revision: D21325071
fbshipit-source-id: d4d6cbdb10a2bcf955ee371278bf2bbbd5f5122c
Summary:
Microwave doesn't normally allow writes, which can cause cache warmup to fail
if master has underived commits. So, let's go back in bookmarks history to
whatever is most recent and derived. We can do so using the existing logic we
use in the warm bookmarks cache.
Reviewed By: farnz
Differential Revision: D21325485
fbshipit-source-id: 11e758cd512a22e02704ac34458fead18c284c20
Summary:
This updates cache_warmup to new futures, since I'd like to do a little bit of
work in there. This also changes a bit of functionality: until now we were
roundtripping through a hg changeset id un-necessarily so that updates it to
just use the bcs id instead.
Reviewed By: mitrandir77
Differential Revision: D21325484
fbshipit-source-id: 4d296c5fbe7c21dda681aed4ed9c572a38246893
Summary:
Upgrade to the 1.10.0 release. This includes some new features like the
`GTEST_SKIP()` macro.
Reviewed By: genevievehelsel
Differential Revision: D21309360
fbshipit-source-id: 163db628fc99aaa786aeb207f35c7d6295cb5e25
Summary:
Update the generated `run_cmake.py` script to tell ctest to print the test
output on failure. Also pass in a `-j` flag to run tests in parallel by
default.
These flags are already passed in by default when running `getdeps.py test`;
this simply updates this developer utility script to do the same.
Reviewed By: wez
Differential Revision: D21307806
fbshipit-source-id: 42045b0f9362494042c79bc946a1004ff8ad98b6
Summary:
Instead of multiple linear array scans to determine the type of a FUSE
request, use a single lookup table. This is a small optimization, but
it makes the code a bit nicer too.
Reviewed By: wez
Differential Revision: D21314720
fbshipit-source-id: 5b6700ad5bb8e353da1e457de1533e6a626e8f68
