Preparing release v1.13.0

[albertteoh]

Signed-off-by: albertteoh [email protected]

Which problem is this PR solving?

• Prepares jaeger-ui for release of v1.13.0

Short description of the changes

• Updates changelog and package.json appropriately.

[codecov]

Codecov Report

Merging #699 (209fd51) into master (dac6913) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #699      +/-   ##
==========================================
- Coverage   94.42%   94.39%   -0.04%     
==========================================
  Files         230      230              
  Lines        5959     5959              
  Branches     1448     1448              
==========================================
- Hits         5627     5625       -2     
- Misses        298      300       +2     
  Partials       34       34              

Impacted Files	Coverage Δ
...nents/TracePage/TraceTimelineViewer/SpanBarRow.tsx	72.41% <0.00%> (-6.90%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dac6913...209fd51. Read the comment docs.

[jpkrohling]

I would like to get #702 in before this release.

[yurishkuro]

what does it mean to start from 10 through to 1?

[albertteoh]

The motivation for this change is to add test coverage for the following code block, which was blocking this PR from passing builds:

jaeger-ui/packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/SpanBarRow.tsx

Lines 118 to 119 in df17e8d

	longLabel = `${labelDetail} | ${label}`;
	hintSide = 'left';

I don't know how this code coverage issue appeared given my only changes were to the changelog, but in any case, thought I'd try to fix it as it seems to be the best option for me to unblock the release (please advise if I'm wrong).

The above code block uses the start and end view bounds to determine where the hint label should appear when mousing over the span timeline. So if there's more whitespace to the left of the span timeline than the right, show the label to the left, otherwise, show it to the right.

Realistically, these bounds seem to range between 0 and 1 and so 10 is a little extreme to be honest, but it does the job to get the line coverage for the first if block, and it looks like the else case is covered by other tests. Please let me know if you think this number should be more realistic or if there's a better way to fix the code coverage failure.

[yurishkuro]

seem to range between 0 and 1 and so 10 is a little extreme to be honest

And out of range, most importantly. I am not familiar with the test, but having 10 here is just going to confuse someone else at some time in the future.

I would remove this change. We can ignore the code cov diff for the purpose of this PR, since the diff is coming from a flaky test.

[albertteoh]

Agree and reverted. The "Squash and merge" button is greyed out for me due to the codecov failure; how do we ignore it and proceed with merging this PR?

[yurishkuro]

booked a ticket for flaky coverage #704

[yurishkuro]

I merged it - probably requires admin rights on the repo.

[albertteoh]

Thanks @yurishkuro!