13:48 <pq> What happens when multiple jobs in the same pipeline all produce the same artifacts: reports: cobertura: in Gitlab? Does the job that finished last win?

13:49 <pq> err, I mean the cobertura files are not all the same, just that several jobs produce a reports:cobertura artifact.

14:23 <daniels> \_o_/

15:08 <shadeslayer> pq: afaik every artifact is stored under the jobid/artifact space

15:08 <shadeslayer> so they're all unique IIRC

15:08 <pq> shadeslayer, yeah, but Gitlab will load only one (right?) to use in the MR page diff view?

15:08 <pq> so which one?

15:09 <shadeslayer> ah, so what I recall is that gitlab would coalesce junit reports

15:10 <shadeslayer> but I'm not sure what cobertura is

15:10 <shadeslayer> Once configured, if you create a merge request that triggers a pipeline which collects coverage reports, the coverage is shown in the diff view. This includes reports from any job in any stage in the pipeline. The coverage displays for each line:

15:10 <shadeslayer> https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html

15:10 <pq> cobertura is test code coverage report, and Gitlab can show red vs. green markers in the diff view based on whether the line was executed or not.

15:11 <shadeslayer> ah kinda like rcov

15:11 <pq> hmm, maybe it does coalesce them then?

15:12 <shadeslayer> so I'm guessing you have tests that hit the same code path multiple times? across multiple jobs?

15:13 <shadeslayer> basing it off my past experience with rcov, I'd say gitlab should coalesce them

15:13 <pq> yes, and some jobs (those that use clang to compile the program) report obviously wrong results.

15:13 <shadeslayer> my guess would be that if any tool marks a line of the diff as being buggy, it would be marked as buggy

15:14 <pq> no, the markers are executed vs. not executed (vs. no code to execute for no marker).

15:15 <pq> Gitlab does not always do the sensible thing, which is why I'm wondering. :-)

15:15 <shadeslayer> ^^ only one way to find out :)

15:16 <pq> like if you make a comment in a diff view of a MR and choose specific lines of code, then someone lookin at your comment cannot see what lines you selected and Gitlab adds extra context lines that are indistinguishable.

15:16 <shadeslayer> pq: again from my rcov days, if a single test executed a line, it would be marked green, IIRC there were also statistics like how many tests hit that path

15:17 <pq> sure

15:17 <pq> my feeling is that the coverage reporting in MR diffs is not reliable, it is sometimes missing.

15:18 <pq> so I started wondering, could be cobertura report be sometimes removed, replaced, or corrupted, particularly seeing how multiple jobs are emitting what /should/ be the same report (but looks like is not)

15:19 <pq> it definitely takes a good while after a pipeline completes before any visualisation appears

15:19 <pq> long enough that you think it didn't work at all

16:12 <emersion> danvet: i'

16:12 <emersion> danvet: i've pinged keithp multiple times about the domain transfer, but he's not replying

16:21 <danvet> emersion, thanksgiving?

16:21 <emersion> well, it's been…

16:21 <danvet> but yeah keithp is occasionally awol, I'll nag in the bod meeting next week

16:22 <emersion> it's been 1 month

16:22 <emersion> ok thanks

16:23 <danvet> also if it doesn't pan out, *shrug*

16:23 <danvet> we just don't transfer

16:24 <danvet> those two last domains aren't really part of our critical infra

16:26 <emersion> yeah it's not that of a big dea;

16:26 <emersion> deal*

16:26 <emersion> was just wondering how much pinging i should keep trying to do