Problem: Tracker doesn't store bug info in DB

[teodorus-nathaniel]

Sub of

• Goal: track amount of bugs per author (productised version) #273

[teodorus-nathaniel]

@georgeciubotaru for this problem, I'm thinking of storing this in DB only when the PR is merged
wdyt?

[georgeciubotaru]

@teodorus-nathaniel This should be the event of adding the bug information via comment, and should be inserted in the Bigquery DB. The action should happen only when it is added

[teodorus-nathaniel]

I'm thinking of saving it when its closed because, if we insert it before the close, there may be too many case we need to catch:

• PR changed to non fix:, remove the data
• The report comment edited: edit the data
• The report comment deleted: delete the data

that's why I'm thinking of just adding the data to db after its closed, where it's the finalized comment

[georgeciubotaru]

@teodorus-nathaniel Kinda complicated, but we should run this only if the PR is marked for review, until that let's not display anything.
Basically, altering the comment or title are edge cases and we can fix them in future iterations if that will be the case.

Let's do the simple case, then we can try more complicated ones

[teodorus-nathaniel]

@georgeciubotaru just to confirm, we should still insert to db when the user inserted the comment instead of when the PR merged right?

but what's the concern of inserting the data to DB when the PR is merged? it seems simpler flow to manage for me

[georgeciubotaru]

@teodorus-nathaniel You can go your way, the result: we should see the bug_introduced events in the Bigquery

[teodorus-nathaniel]

@georgeciubotaru if I send events to BigQuery and save the data to DB, will this also resolves #321 ?

[georgeciubotaru]

@teodorus-nathaniel we need bug info only in Bigquery, not in the DB.

will this also resolves #321 ?

Yes

[teodorus-nathaniel]

@teodorus-nathaniel we need bug info only in Bigquery, not in the DB.

In that case, Ill close this issue then, we have the BigQuery related problem in #321