CrdtMerge API web service #1136
Conversation
C# Unit Tests75 tests 75 ✅ 5s ⏱️ Results for commit 4e72940. ♻️ This comment has been updated with latest results. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Running into sillsdev/flexbridge#409 while working on this. There's no reason built into FLExBridge why FixFwData.exe has to have an .exe filename. I created this problem for myself because I didn't fully understand how FlexBridge worked at the time, then spent a lot of effort working around the problem I myself created. But really, I should just relax the requirements of where FixFwData.exe needs to be located, and then everything will work as it should. |
|
About to rebase on top of current develop to fix LexBox.sln merge conflicts, then I'll take this out of draft status since it's ready for initial review. Not ready to push yet since I still need to create the k8s deployment (and figure out where it should store CRDT projects), but I just ran this successfully on my dev machine, and synced sena-3 from my local LexBox into a CRDT project. |
This is basically the `dotnet new` template for an ASP.NET server, with the example API removed and replaced with one that takes a project code.
This is copied nearly as-is, but with an ASP.NET Core API wrapped around it instead of a System.CommandLine set of arguments and options. Next step would be to move the implementing classes into a CrdtMerge.Core library so that FwLiteProjectSync can reference them and we DRY ourselves out again.
This requires removing `<SelfContained>true</SelfContained>` from the FwLiteProjectSync.csproj file, but if in the future we do decide to deploy FwLiteProjectSync as a self-contained exe, we can just pass the appropriate compiler flag on the command line. Meanwhile, this avoids needing to create a CrdtSync.Core library while still sharing code.
Avoids more duplication
These are implicit in the Microsoft.NET.Sdk.Web SDK, so we don't need to redeclare them here.
Needed for VS Code C# extension to give proper Intellisense
This is a little finicky, because it requires running from the directory where FixFwData.exe is located. At some point I'll fix that too-strict requirement in LfMergeBridge and then the extra build steps aorund FixFwData.exe can go away.
This will allow us to create a Services class that's dependency injected and gets thigns like HgConfig, while the functions in the Helpers class take all their required config in their params and remain static.
Next step is to clean up slightly-messy code and separate properly into different files.
No more lambda that just calls the implementation; just pass the implementation method in directly as that's cleaner.
Compiles but doesn't run, as LcmCrdtKernel.ConfigureDbOptions complains that Project is null. But we have the basic skeleton of the tool now.
Now LfMergeBridge can find FixFwData with and without the .exe extension
We need to obtain two services just-in-time: CurrentProjectService, and IMiniLcmApi. Both of these need projectsService.SetProjectScope to have been called before they get initialized.
rmunn
force-pushed
the
feat/crdt-merge-api
branch
from
7673487 to
b1876ea
Compare
CRDT handles conflicts better than Send/Receive. So first we do a Send/Receive (or clone if the .fwdata file doesn't exist yet), then we sync the .fwdata and CRDT, and then we do another Send/Receive of the sync results in order to push them to Lexbox.
Also rename SRConfig to CrdtMergeConfig since it's not really about configuring Send/Receive any more, it's about configuring the whole CrdtMerge application.
The template creates a `/weatherforecast` URL. We deleted it from our code, but it was still lingering in a couple of places. Gone now.
Now that we're not making it an exe, it's not allowed to use top-level statements, so we need to move those into a real Program class with a static Main method.
|
Now that this PR is ready, I should work on #1155 because I realized partway through that it's going to be necessary once we're doing S/R of real projects. |
|
A bunch of FwLite tests are now failing because of the changes we made to how projects are located. Will look at that tomorrow. |
…f the loader and just into the Project list, the path is then passed via the FwDataProject class
Fixes #1091.
Work done:
Still remaining:
Create k8s deploymentPut off for later PRWrite tests to exercise it by sending API requests and verifying correct results happenPut off for later PRTo test
../../hgweb/reposif you want, otherwise the test will put files intolexbox/hgweb/reposdotnet runinside the CrdtMerge folderdotnet runlogs while you waitlexbox/hgweb/repos, or wherever you put them