Epic: Flexible platform support
- Dominant language
- Python
- Stars
- 13
- Forks
- 17
- Avg merge
- 6h 59m
- Merged PRs (30d)
- 1
Description
> [!NOTE]
> Migrated from [augurlabs/augur#3594](https://github.com/augurlabs/augur/issues/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 #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 #156 )
- We should probably be standardizing the way tasks are structured and set up ( #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.
Contributor guide
Assessment
This issue has not been assessed yet.