At the moment Bilara uses git commands (like git add, git commit) in a subprocess.
Both performance and reliability could be improved by using a library like pygit2 to directly manipulate the repository instead of relying on the "user-friendly" behavior of basic git commands. Why? Command line utilities are intended to give feedback to the user if something untoward happens
One important thing is to ensure that concurrency is handled gracefully, sometime that Bilara still occasionally fails at resulting in the requirement for an administrator to intervene, this requires that the code be stress tested by having multiple threads/processes modify the repository simultaneously in an attempt to create race conditions. If the code that updates the file can withstand a stress test of multiple threads updating dozens of files simultaneously.
Managing concurrency correctly is critical because bilara uses some multi-threading. For example when the Github repo is updated, that triggers a webhook that updates the repository. A multiprocessing friendly locking strategy must be used to ensure that files are updated without interference. Git does have its own index lock, but git commands fail rather than waiting for the index lock to be released, so this has to be accounted for by retrying.
In preliminary stress testing, pygit2 has performed much better with concurrency (like 10 threads bombarding the git repo with thousands of updates), being both much more performant in terms of speed (probably 100x faster) and it was easier to write code that doesn't result in unrecoverable situations.
At the moment Bilara uses git commands (like git add, git commit) in a subprocess.
Both performance and reliability could be improved by using a library like pygit2 to directly manipulate the repository instead of relying on the "user-friendly" behavior of basic git commands. Why? Command line utilities are intended to give feedback to the user if something untoward happens
One important thing is to ensure that concurrency is handled gracefully, sometime that Bilara still occasionally fails at resulting in the requirement for an administrator to intervene, this requires that the code be stress tested by having multiple threads/processes modify the repository simultaneously in an attempt to create race conditions. If the code that updates the file can withstand a stress test of multiple threads updating dozens of files simultaneously.
Managing concurrency correctly is critical because bilara uses some multi-threading. For example when the Github repo is updated, that triggers a webhook that updates the repository. A multiprocessing friendly locking strategy must be used to ensure that files are updated without interference. Git does have its own index lock, but git commands fail rather than waiting for the index lock to be released, so this has to be accounted for by retrying.
In preliminary stress testing, pygit2 has performed much better with concurrency (like 10 threads bombarding the git repo with thousands of updates), being both much more performant in terms of speed (probably 100x faster) and it was easier to write code that doesn't result in unrecoverable situations.