Update Github installation IDs to be DB backed for better performance
While testing the Github installations precache with production credentials, we could not get the installations to load in under a minute, and would consistently time out. This is poor performance, and we should look at replicating the Drupal solution of putting the installation information into the database, and using a scheduled task to keep it up to date.
Activity
added statewip team:webdev labels
assigned to @malowe
@cguindon I'm making new tables for this feature, and I want to make sure they make sense before I commit to them fully.
I've split the relationship into 2 tables to keep the tables cleaner and reduce the duplication of strings in the DB. I've added lastUpdated to use a single timestamp when I update to watch for stale entries. When I finish updating the records, I can look for entries that weren't touched and remove them to keep the data from having stale entries for renamed/removed repositories in organizations. I can do the same for the installation records and cascade delete them if the installation wasn't updated/validated.
GithubApplicationInstallations
Column Type Description id serial uid for the app installation appId int the application ID from GH installationId int the installation ID for the tracked install from GH lastUpdated datetime Time that this was last touched GithubApplicationInstallationRepositories
Column Type Description id serial uid for the app installation repository record installation_id serial FK The FK key for the installation this entry is linked to repository string the full repository name of the repo associated with the given install, e.g. eclipse/jetty lastUpdated datetime Time that this entry was last touched The alternative is I smush these tables together and have a ton of duplicated numbers for the app and installation IDs, like the below sample:
id appId installationId repository lastUpdated 1 12345 123456789 eclipse/jetty 09-13-2023T12:00:00-500 2 12345 123456789 eclipse/not-jetty 09-13-2023T12:00:00-500 3 12345 123456789 eclipse/cool-stuff 09-13-2023T12:00:00-500 4 12345 987654321 jakartaee/data 09-13-2023T12:00:00-500 After an external conversation, we agreed that a better approach would be a unified table that uses the type to better target the types, and pass both the org and repo name when looking up installation instead. Below is the table definition we've switched to
Column Type Description id serial uid for the app installation appId int the application ID from GH installationId int the installation ID for the tracked install from GH type string The type of installation, either repository or organization name string name of the entry, either the org name or repository name lastUpdated datetime Time that this was last touched
mentioned in merge request !155 (merged)
mentioned in commit c479ed3a
mentioned in commit 17b75791
removed statewip label
