Repository navigation
Epic: Flexible platform support #176
Description
Note
Migrated from augurlabs/augur#3594
Originally opened by @MoralCode on 2026-01-16
Currently Augur is largely dependent on the github API (since that was what it was originally written for)
When considering support for new platforms, there are lots of ways we need to be flexible/things we need to do to account for other platforms that dont quite work the same as github. For example:
- We need underlying support for the API of the platform (i.e. github/gitlab endpoint paths, this is the obvoius one)
- We need support for changing the domain we use to make requests with that api implementation (i.e. some platforms have multiple instances, i.e. selfhosted forgejo, github/github enterprise Add option to use Github Enterprise API for api key checks #110, etc)
- We need to associate API keys with the combination of domain and platform that is in use (someones GHE api key prob wont work on regular github)
- Different platforms may have different specifics for handling API keys (i.e. github does rate limits for graphql and REST independently for the same key)
Also
- Different platforms provide different sets of data, so we likely need to adjust the table schema to accomodate as many useful pieces as possible (without just creating platform specific columns Cross-contamination between github and gitlab columns in contributors table #156 )
- We should probably be standardizing the way tasks are structured and set up ( Use Classes to enforce consistent APIs #107 )
- We should make sure that our various interfaces show information about all of the platforms (notably the CLI for checking the rate limits left on all configured keys)
- Having an admin panel in the web ui that can manage keys is probably going to help users a lot.
This is an absolutely huge task thats going to need to be broken down pretty small and done very strategically to keep us on track for adding more platforms this year.
Activity
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@Sukuna0007Abhion 2026-01-16Hi @MoralCode if it's open for us.. I have the suggestion as I worked on #107 and want to complete 1 part of this task via this #107 issue..
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-01-16based on a slack message i posted:
im less worried about the logic of querying the APIs - its more of managing the associations between which platform implementation we use, which domain we are querying, and which keys we use to do that query, and where the data goes afterwards.
i.e. its more about getting the infrastructure and logistics of querying data in place in a way thats reusable - right now our solutions to a lot of that are: 1) assume the domain never changes, 2) have one list of API keys specifically for that platform, and 3) making new table columns for new platforms.
All of that doesnt really scale well.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-01-16some aspects of this are more critical than others too. I'm less worried about the API keys and domains since we can introduce a new platforms table or columns in an existing table or add it to the config or make a new config or something for storing this information and use those for new platforms while we migrate the old ones.
The biggest concern/critical item is more on the "where do we store the data" side - we are currently labeling DB columns based on the platform, and that's not scalable and cannot be fixed by making a new table and running the new solution in parallel until the old one is migrated.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-01-16https://github.com/chaoss/augur/issues/3363 splitting the contributors table may help, but as was mentioned in a recent maintainers call, we NEED to preserve the contributor resolution process, which means understanding the process (and probably finding and fixing bugs with it)
platformtable to enable custom domains #293repo_src_idto being globally unique? #312MoralCode commentedon May 20, 2026
We are also likely going to need helper functions that can:
MoralCode commentedon Jun 29, 2026
Quick diagram of an approximately correct relationship between all the various parts of this. Some things are still missing.
For now i dont want to make collection tasks (not pictured but they operate on repo urls) too "general purpose" until we know how similar the APIs (and thus the functions we should have in the data access classes) are. For the early steps i think its fine to define different variants of the same task for the different platform types (even if it results in some duplicate code) - i.e. we should assume for now that a specific task will always be for one platform type
ContributorUUIDto handle new instances? #511