Description
This is how github connection page looks like at the moment, let's separate all fields into to 2 parts

- connection part: including the very essential settings that allow DevLake to connect to github api server
- configuration part: settings used for data extraction, standardization, enrichment, things of that natue
This works fine when user need to download data from a single repo on github.
However, during v0.9 patching process, we ran into following situation:
- We have to collect multiple repos from github into a single DevLake database
- Those repos share the same connection part, but may or may not share the same configuration part (repos from same org likely to share same configuration part, but not neccessary)
The workaround we chose, was to change configuration part right before we collect each repo. Obviously, this is not a long term solution that can be presented to users:
- Recurring pipeline (blueprint) would not work
- Due to reason 1, user have to manually collect multiple repos, go back and forth between connection and pipeline
Describe the solution you'd like
I don't have a clean solution at this point, so, let me list out some factors that have to be considered:
configuration part is specific to the plugin, like github configuration can be completely different than jira's.
configuration part may need validation
configuration part may rely on connection part on usablility, like jira epic key need jira connection to fetch options for user to select.
- plugin may or may not need connection/configuration settings, like
refdiff, it needs neither
- we may have to solve Multi-DataSource before this, because they could have like 1 vs Many relationship
repos are connecting to configurations, do we save their relationship or accepting configuration id from options, or accepting whole configuration from options?
Has the Feature been Requested Before?
No
Description
This is how github connection page looks like at the moment, let's separate all fields into to 2 parts

This works fine when user need to download data from a single repo on github.
However, during v0.9 patching process, we ran into following situation:
The workaround we chose, was to change configuration part right before we collect each repo. Obviously, this is not a long term solution that can be presented to users:
Describe the solution you'd like
I don't have a clean solution at this point, so, let me list out some factors that have to be considered:
configuration partis specific to the plugin, like github configuration can be completely different than jira's.configuration partmay need validationconfiguration partmay rely onconnection parton usablility, like jira epic key need jira connection to fetch options for user to select.refdiff, it needs neitherreposare connecting toconfigurations, do we save their relationship or accepting configurationidfromoptions, or accepting wholeconfigurationfromoptions?Has the Feature been Requested Before?
No