Implements LRU cache for git repos on disk

[jpmcb]

LRU Cache

The GitRepoLRUCache struct and associated methods is a "Least Recently Used" cache whose main element is the GitRepoFilePath struct (which in itself represents an on-disk git repository).

This LRU cache differs from a typical LRU cache in a few ways:

• Eviction happens based on a configured "minimum free disk space" (in Gbs) variable. When the amount of free disk is less than this configuration, the cache will evict the least frequently used repos (and delete them from the disk)
• The cache supports parallel processing (through locking mutexes) and is designed to ensure no disruption across many different operations of the same type on the same element.

Git provider wrappers

The GitRepoProvider is an interface that provides a flat API surface for performing operations with many different git providers (i.e., with the LRUCacheGitRepoProvider or the InMemoryGitRepoProvider). The FetchRepo method on this interface returns a GitRepo, another interface that wraps a go-git repository (but also provides the necessary API surface area for different git repo providers to do the necessary cleanup / prep for those repos).

Additional changes

• The hack/setup.sh script will now wait for the PostgresClusterStatus to be running before attempting to apply the database migrations. This was a flake that I ran into where the script would fail on occasion (because the postgres cluster was not yet ready)
• Running the service with --dubug will print debug logs
• Implemented the GetLastCommit function on the database handler which now returns the time.Time of the last git commit for that repo. This is used to only process commits "after" that date time (this is a huge performance improvement)
• Use UTC for all timestamps.

What type of PR is this? (check all applicable)

• [x] 🍕 Feature
• [ ] 🐛 Bug Fix
• [ ] 📝 Documentation Update
• [ ] 🎨 Style
• [ ] 🧑‍💻 Code Refactor
• [ ] 🔥 Performance Improvements
• [ ] ✅ Test
• [ ] 🤖 Build
• [ ] 🔁 CI
• [ ] 📦 Chore (Release)
• [ ] ⏩ Revert

Related Tickets & Documents

Closes #14

Mobile & Desktop Screenshots/Recordings

N/a

Added tests?

• [x] 👍 yes
• [ ] 🙅 no, because they aren't needed
• [ ] 🙋 no, because I need help

Added to documentation?

• [x] 📜 README.md
• [ ] 📓 docs.opensauced.pizza
• [ ] 🍕 dev.to/opensauced
• [ ] 📕 storybook
• [ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

N/a

[optional] What gif best describes this PR or how it makes you feel?

^ When you evict elements from the cache

[brandonroberts]

Easy to read and well documented and tested. I only had minor documentation nits but not worth holding it up.

Just for reference, are there any limitations on the number of repos that can be indexed on disk concurrently?

[jpmcb]

Just for reference, are there any limitations on the number of repos that can be indexed on disk concurrently?

Good question: short answer, with the caching approach, no, there's no limit to the number of repos that can be indexed concurrently.

The only constraints are:

• Cache operations (putting to the cache, making new directories, updating the position of elements in the cache, etc.) are locked behind the cache's mutex. But this mutex unlocks relatively quickly after operations on the cache itself have finished.
• Individual elements cannot be operated on at the same time and are locked behind their own mutex: this prevents repos on disk from getting reaped or updated while another thread is performing operations. I.e., this prevents a nasty edge case where a repo is being cloned (and maybe taking time to receive object), gets pushed to the back of the cache, and is reaped before cloning is completed in the first thread.

Otherwise, the server's route handling will spin up a new thread for any request that comes in.

[jpmcb]

I only have questions about whether we should create issues and link them next to the TODOS.

My plan was to merge this and then create issues around those TODOs: I didn't want to create issues for code that hadn't merged yet 😅

[jpmcb]

Merged. Planning to back-fill issues for hanging todos so we can keep tracking them.