Open xtuchyna opened 3 years ago
/kind feature /kind demo
/assign @xtuchyna
Why not create a config file that is read by MI and processed by a method. The config file would be an input the method, the purpose of the method is to create a dict, the dict is what MI should aggregate...
aggregate:
- "org1/repo1": [ "PR", "issue" ]
- "org1/repo2": [ "PR, issue" ]
- "org1/repo3": ["PR"]
- "org2/repo1: ["PR", "issue"]
- "org2/repo2": ["PR"]
The config for this could look like:
aggregate:
orgs:
- "org1"
- "org2"
entities:
- PR
- issue
excludeRepos:
- repo3
repos:
- org1/repo3:
- org2/repo2
entities:
- PR
pretty much like what Tide is doing at https://github.com/thoth-station/thoth-application/blob/master/prow/overlays/cnv-prod/config.yaml#L162
/triage needs-information
/remove-triage needs-information
@xtuchyna are you working on this? if so, please lifecycle it, and set a prio
/priority backlog
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten
/remove-lifecycle rotten
/priority-important soon
@xtuchyna: The label(s) priority/soon
cannot be applied, because the repository doesn't have them.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
/close
@sesheta: Closing this issue.
/reopen /remove-lifecycle rotten
@xtuchyna: Reopened this issue.
/priority-important soon
I will take that as /triage accepted
User story
As a
mi
dataset requester, I want to specify github target and its entities, so that I can simply make PR to the global configmap that will have it registered.Additional context When aggregating data for
mi
repositories (either for generalmi
inspection or akebechet
oriented analysis), the repositories and organization names are stored here https://github.com/thoth-station/thoth-application/blob/master/mi-scheduler/base/configmaps.yamlHowever, this is not scalable and user-specific, because everything is stored inside the comma-sep styled string (it is then parsed in
mi-scheduler
). This also does not allow to specify entity individually for repo/org.With recent changes to the
schedule
method incommon
formi
it is possible to specify repos with specific entities, so the only thing remains to store the list of tuples [ (repo/ord, entities), ... ] to the json file and load it as a configmap.Acceptance Criteria
json
file.Linked epics / issues https://github.com/thoth-station/mi-scheduler/pull/139