Commit Graph

11 Commits

Author SHA1 Message Date
Stanislau Hlebik
01a41013e1 mononoke: remove noisy logging
Summary: It's very spammy

Reviewed By: ikostia

Differential Revision: D24418801

fbshipit-source-id: 35c804764e9f65a49ba73a0d983636665dae1841
2020-10-20 07:41:48 -07:00
Kostia Balytskyi
081ca3e7d6 common: add iterhelpers
Summary:
This just adds a single fn. I did not come up with a better place/name to put
it, suggestions are welcome. Seems generic enough to belong at the top-level
common location.

I've already needed this twice, so decided to extract. Second callsite will be further in the stack.

Reviewed By: StanislavGlebik

Differential Revision: D24080193

fbshipit-source-id: c3e0646f263562f3eed93f1fdbab9a076729f33c
2020-10-04 23:51:03 -07:00
Kostia Balytskyi
9981ab8454 mononoke: use parent config version if it's available for a single-parent case
Summary:
Let's start actually fixing what commit sync config version is used to remap a commit i.e. we
should use a commit sync config version that was used to remap a parent instead
of using a current version. See more details in
https://fb.quip.com/VYqAArwP0nr1

This diff fixes one particular case and also leaves a few TODOs that we need to
do later

Reviewed By: krallin

Differential Revision: D23953213

fbshipit-source-id: 021da04b0f431767fec5d1c4408287870cb83de1
2020-09-28 10:20:16 -07:00
Kostia Balytskyi
0f47188bd8 mononoke: change TestLiveCommitSyncConfig logic
Summary:
TestLiveCommitSyncConfig is supposed to be a test replacement of
CfgrLiveCommitSyncConfig, however it was quite a different semantic. In
particular, it wasn't even possible to have two versions of the mapping for the
single repo.

This diff changes that. Now we'll have a method to add commit sync config
version, and mark/remove a version as current

Reviewed By: krallin

Differential Revision: D23951202

fbshipit-source-id: 242b4f088f67dac504544987e484cc290ee4e400
2020-09-28 10:20:16 -07:00
Stanislau Hlebik
092875e01d mononoke: remove version from CommitSyncRepos
Summary: Finally remove version_name from CommitSyncRepos. Note that this diff adds a few TODOs that we'd need to fix later.

Reviewed By: ikostia

Differential Revision: D23929010

fbshipit-source-id: c72130af548ac7b26bc20ddaac9a59562cc75e0b
2020-09-25 14:21:07 -07:00
David Tolnay
0cb8a052f5 Update formatter to rustfmt 2.0
Reviewed By: zertosh

Differential Revision: D23591021

fbshipit-source-id: e664aa2fdd3aaa457796a59080be6b94f604a112
2020-09-09 07:52:33 -07:00
Kostia Balytskyi
fc61c74f23 live_commit_sync_config: make scs xrepo-lookup watch live changes
Summary:
When we change `CommitSyncConfig`, we want to not have to restart `scs` servers, and instead have them pick up the new config by using `LiveCommitSyncConfig`.

This diff turned out larger than I expected, mainly due to the need to introduce various things around `TestLiveCommitSyncConfig`:
- `TestLiveCommitSyncConfig`: the trait implementer to use in `mononoke_api::Repo`
- `TestLiveCommitSyncConfigSource`: the helper struct to keep around for new values injection (very similar to how our `ConfigStore` has an inner `ConfigSource`, which can also be `TestSource`, but here injected values can be `CommitSyncConfig` instead of JSON).
- all the places in integration tests, where `setup_configerator_configs` is now needed (I plan to start setting up configerator configs always in a separate diff, as it is cheap)

Here are the explanations for a few things I think may be not immediately obvious:
- I removed the `Clone` bound from `LiveCommitSyncConfig` trait, as `Clone` traits [cannot be made into trait objects](https://doc.rust-lang.org/book/ch17-02-trait-objects.html#object-safety-is-required-for-trait-objects)
- `TestLiveCommitSyncConfigSource` vs `TestLiveCommitSyncConfigSourceInner` discrepancy is to ensure nobody should instantiate `TestLiveCommitSyncConfigSourceInner` outside of `live_commit_sync_config/src`
- I am aware of the ugly discrepancy between the main `--mononoke-config-path`, which is used to load initial configuration and can be both a file-based and a configerator-based config; and `--local-configerator-path`, used to override config sources for `Tunables` and `LiveCommitSyncConfig`. Ideally these two should just be unified somehow, but that is a little out of scope of this diff (I've already added it to the dirt doc though).
- in `mononoke_api::Repo` there are methods `new_test_xrepo` and `new_test_common`, which changed from maybe accepting just a `CommitSyncConfig` to now maybe accepting both `CommitSyncConfig` and `LiveCommitSyncConfig`. It can be made a bit cleaner: I can just query `CommitSyncConfig` from `LiveCommitSyncConfig` in `new_test_common` and avoid having two args. I was too lazy to do this, lmk if you feel strongly about it.

Reviewed By: StanislavGlebik

Differential Revision: D22443623

fbshipit-source-id: 0d6bbda2223e77b89cc59863b703db5081bcd601
2020-07-21 09:09:23 -07:00
Kostia Balytskyi
75db021d70 live_commit_sync_config: make it into a trait
Summary:
The goal is to make it easier to implement unit tests, which depend on `LiveCommitSyncConfig`. Specifically, `scs` has a piece of code, which instantiates `mononoke_api::Repo` with a test version of `CommitSyncConfig`. To migrate it to `LiveCommitSyncConfig`, I need to be able to create a test version of that. It **is** possible now, but would require me to turn a supplied instance of `CommitSyncConfig` back into `json`, which is cumbersome. Using a `dyn LiveCommitSyncConfig` there, instead of a concrete struct seems like a good idea.

Note also that we are using this technique in many places: most (all?) of our DB tables are traits, which we then implement for SQL-specific structs.

Finally, this diff does not actually migrate all of the current users of `LiveCommitSyncConfig` (the struct) to be users of `LiveCommitSyncConfig` (the trait), and instead makes them use `CfgrLiveCommitSyncConfig` (the trait impl). The idea is that we can migrate bits to use traits when needed (for example, in an upcoming `scs` diff). When not needed, it's fine to use concrete structs. Again, this is already the case in a a few places: we sometimes use `SqlSyncedCommitMapping` struct directly, instead of `T: SyncedCommitMapping` or `dyn SyncedCommitMapping`.

Reviewed By: StanislavGlebik

Differential Revision: D22383859

fbshipit-source-id: 8657fa39b11101684c1baae9f26becad6f890302
2020-07-08 08:34:06 -07:00
Kostia Balytskyi
6d5b3ac1f2 live_commit_sync_config: add versions accessors
Summary:
This diff adds two new bits of functionality to `LiveCommitSyncConfig`:
- getting all possible versions of `CommitSyncConfig` for a given repo
- getting `CommitSyncConfig` for a repo by version name

These bits are meant to be used in:
- `commit_validator` and `bookmarks_validator`, which would
  need to run validation against a specific config version
- `mononoke_admin`, which would need to be able to query all versions,
  display the version used to sync two commits and so on

Reviewed By: StanislavGlebik

Differential Revision: D22235381

fbshipit-source-id: 42326fe853b588849bce0185b456a5365f3d8dff
2020-07-06 14:00:36 -07:00
Kostia Balytskyi
ef87f564bc add newtype for CommitSyncConfigVersion
Summary:
This is to avoid passing `String` around. Will be useful in one of the next
diffs, where I add querying `LiveCommitSyncConfig` by versions.

Reviewed By: krallin

Differential Revision: D22243254

fbshipit-source-id: c3fa92b62ae32e06d7557ec486d211900ff3964f
2020-06-26 02:45:26 -07:00
Kostia Balytskyi
ed34e343c5 commmit_rewriting: introduce live_commit_sync_config
Summary:
`LiveCommitSyncConfig` is intended to be a fundamental struct, on which live push-redirection and commit sync config for push-redurector, x-repo sync job, backsyncer, commit and bookmark validators are based.

The struct wraps a few `ConfigStore` handles, which allows it to query latest values every time one of the public methods is called. Callers receive parsed structs/values (`true`/`false` for push redirection config, `CommitSyncConfig` for the rest), which they later need to use to build things like `Mover`, `BookmarkRenamer`, `CommitSyncer`, `CommitRepos` and so on. For now the idea is to rebuild these derived structs every time, but we can later add a memoization layer, if the overhead is going to be large.

Reviewed By: StanislavGlebik

Differential Revision: D22095975

fbshipit-source-id: 58e1f1d8effe921b0dc264fffa785593ef188665
2020-06-25 03:28:08 -07:00