[FOLIO-3426] translation PRs in UI repos wipe out code-coverage artifacts Created: 22/Feb/22  Updated: 10/May/23

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: TBD
Reporter: Zak Burke Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint: DevOps Sprint 160
Development Team: FOLIO DevOps
RCA Group: TBD

 Description   

Overview: After a translation PR merges, Sonar reports code-coverage as 0.
Summary: There are legit reasons to handle translation PRs differently than regular PRs since they only change content, not code, and (at least historically) tests could be flaky, causing translation PRs to be unreliable. But without tests, no artifacts directory is generated, leading to this unintended side-effect.

Expected Results: Translation PRs should not affect coverage stats.
Actual Results: Translation PRs wipe out coverage stats.

Interested parties: h/t Mikita Siadykh for figuring out the root cause of the 0% coverage reports.
CC: Peter Murray, Anton Emelianov, any thoughts on how we can manage this? No "obvious" solution presents itself to me.



 Comments   
Comment by Peter Murray [ 22/Feb/22 ]

Ooof.  Are these files stored in a directory?  Could the `artifacts` directory from the previous run be copied into the current run near the end of the job?

Comment by Ann-Marie Breaux (Inactive) [ 14/Mar/22 ]

Hi Zak Burke and Peter Murray Which dev team should this be assigned to, and what priority do you think this is?

Comment by Peter Murray [ 14/Mar/22 ]

That is a good question.  Thoughts, Mikita Siadykh  or Zak Burke?

Comment by Zak Burke [ 14/Mar/22 ]

I don't have a good understanding of exactly what happens when a translation PR merges and if/how it interacts (or sidesteps) the regular GA workflows. It could be as simple as "after a translation PR merges, trigger another build on the master branch to fire off the regular build-npm workflow". Peter Murray , John Malconian this feels like a devops thing to me. Do you agree? Anton Emelianov can you help assess the priority?

Comment by Anton Emelianov (Inactive) [ 15/Mar/22 ]

John Malconian It feels that it could be handled on the Jenkins level. Could you please provide your feedback?
CC Zak Burke, Peter Murray

Comment by Ann-Marie Breaux (Inactive) [ 30/Mar/22 ]

Hi John Malconian Zak Burke Peter Murray

Which dev team should own this issue? When it's not assigned to any team, it's not in any backlog that POs or devs are watching, so it gets lost in the Jira ocean. Thank you!

cc: Anton Emelianov

Comment by Zak Burke [ 30/Mar/22 ]

Thanks for the nudge, Ann-Marie Breaux. I think it's mostly Devops, perhaps with some input/insight from Stripes Force or Prokopovych. I will assign it accordingly.

Comment by John Malconian [ 31/Mar/22 ]

Sorry, all. I completely missed seeing this issue. Not sure what the best solution is yet, but it's definitely a DevOps issue.

Comment by John Malconian [ 31/Mar/22 ]

Added to the DevOps "Requests" sprint for planning.

Generated at Thu Feb 08 23:28:02 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.