Use jaeger.thrift #142

pavolloffay · 2017-04-20T13:42:49Z

Resolves #140

codecov-io · 2017-04-20T13:50:43Z

Codecov Report

Merging #142 into master will decrease coverage by 0.09%.
The diff coverage is 77.77%.

@@             Coverage Diff             @@
##             master     #142     +/-   ##
===========================================
- Coverage     79.94%   79.84%   -0.1%     
+ Complexity      455      448      -7     
===========================================
  Files            76       76             
  Lines          1715     1722      +7     
  Branches        188      192      +4     
===========================================
+ Hits           1371     1375      +4     
- Misses          256      261      +5     
+ Partials         88       86      -2

Impacted Files	Coverage Δ	Complexity Δ
...java/com/uber/jaeger/reporters/RemoteReporter.java	`80.95% <100%> (ø)`	`5 <0> (ø)`	⬇️
...a/com/uber/jaeger/senders/zipkin/ZipkinSender.java	`65.07% <100%> (ø)`	`14 <3> (ø)`	⬇️
...aeger-core/src/main/java/com/uber/jaeger/Span.java	`81.81% <100%> (+1.81%)`	`36 <2> (-13)`	⬇️
...-core/src/main/java/com/uber/jaeger/Reference.java	`66.66% <66.66%> (ø)`	`2 <2> (?)`
...ber/jaeger/senders/zipkin/ThriftSpanConverter.java	`81.48% <71.87%> (ø)`	`19 <6> (?)`
...ger-core/src/main/java/com/uber/jaeger/Tracer.java	`85.16% <75%> (-0.13%)`	`16 <2> (+1)`
...reporters/protocols/JaegerThriftSpanConverter.java	`92.3% <80%> (+1.23%)`	`19 <2> (+3)`	⬆️
...c/main/java/com/uber/jaeger/senders/UDPSender.java	`70.9% <86.66%> (+3.56%)`	`11 <4> (+1)`	⬆️
...uber/jaeger/reporters/protocols/TUDPTransport.java	`83.05% <0%> (+5.08%)`	`16% <0%> (+2%)`	⬆️

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 0b48635...5c65b9b. Read the comment docs.

pavolloffay · 2017-04-20T13:56:31Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

          metrics.tracesJoinedSampled.inc(1);
        } else {
          metrics.tracesJoinedNotSampled.inc(1);
        }
-        return parent;


Should be parentSpan reused when using jaeger.thrift?

Without this UI does not show -> for client-server RPC

-> is only shown when RPC is collapsed

it requires span.kind to be set on both sides

what kind of demo app did you try? maybe it's instrumentation issue.

App is instrumented correctly, the problem was that I was trying this PR when SPAN_KIND tags were not added due to zipkin sr,cs.. annotations. Now it is working fine.

pavolloffay · 2017-04-20T14:20:25Z

Do you want to keep ZipkinSender? If so we might need generic sender interface.

yurishkuro · 2017-04-20T15:25:02Z

Yes, we need to keep ZipkinSender, some people are using jaeger-client with Zipkin backend.

I don't think sender interface should be generic, the reporter only has a Span object, and currently reported invokes the transformation from Span to zipkin.thrift. Instead that transformation should be encapsulated inside the Sender, since reporter shouldn't care about the wire format used by the sender. It looks like the Span class already has public visibility on getters so that the senders can transform it without being in the same package.

Another possible change here is to use the approach lightstep used in their Go client, where the Span contains another class RawSpan, which is unsynchronized, and the interface between reporter and senders, or even between tracer and reporters, is the RawSpan - unsynchronized & immutable. Tracer can create it just before calling Reporter.report(), to reduce the number of synchronized blocks to one (instead of one per every getter).

pavolloffay · 2017-04-20T15:41:21Z

Thanks, I will convert Span to the desired type in `Sender.

What about my question about shared span model in RPC?

yurishkuro · 2017-04-20T16:05:33Z

What about my question about shared span model in RPC?

Jaeger model does not reuse span ID between RPC parent / child, each span should get a unique ID.

pavolloffay · 2017-04-20T18:05:28Z

It's ready for an initial review.

yurishkuro

overall lgtm

yurishkuro · 2017-04-20T23:25:30Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

+      Reference preferredParent = references.isEmpty() ? null : references.get(0);
+      for (Reference reference: references) {
+        if (References.CHILD_OF.equals(reference.getType()) &&
+                References.FOLLOWS_FROM.equals(preferredParent.getType())) {


I think it's better to say !References.CHILD_OF.equals

It's fine alternative, anyways is is currently allowing only child and follows.

yurishkuro · 2017-04-20T23:26:55Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

        context = createNewContext(null);
-      } else if (parent.isDebugIDContainerOnly()) {
-        context = createNewContext(parent.getDebugID());
+      } else if (preferredParent.referencedContext().isDebugIDContainerOnly()) {


huh, I guess we never implemented the ability to set baggage externally, as in Go client.

hm... could you explain what is wrong?

No, it's fine, just a note to myself. We want to be able to parse baggage from the request even when there's no trace context. We do it in Go client, but not in Java. I will do a separate pr for that.

offtopic: What is the use case for it?

yurishkuro · 2017-04-20T23:28:23Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

-      if (parent == null || isRPCServer()) {
-        // add tracer tags only to first span in the process
+      // add tracer tags to zipkin first span in process
+      if (zipkinSharedRPCSpan && (preferredParent == null || isRPCServer())) {


this looks like an overloading of this boolean flag. I think it's better to add tracer tags in the Sender, since it's specific to Zipkin. But if it creates too much complexity, I'm ok to leave it here, maybe add a TODO

Originally I had it there, but I had to tweak zipkin thritf convertor and it did not look right, this was cleaner.

yurishkuro · 2017-04-20T23:33:02Z

jaeger-core/src/main/java/com/uber/jaeger/reporters/protocols/ThriftSpanConverter.java

@@ -21,6 +21,11 @@
 */
 package com.uber.jaeger.reporters.protocols;


should this move to jaeger-zipkin module?

+1 I wanted to propose the same.

yurishkuro · 2017-04-20T23:37:52Z

jaeger-core/src/main/java/com/uber/jaeger/senders/InMemorySender.java

@@ -21,11 +21,13 @@
 */
 package com.uber.jaeger.senders;


tbh, no idea why we need this guy. Can only imagine needing it to test RemoteReporter, but then it should be in tests-only.

moved to tests

yurishkuro · 2017-04-20T23:38:42Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

 import lombok.ToString;

 @ToString(exclude = {"spanBuffer", "udpClient", "memoryTransport"})
 public class UDPSender implements Sender {
-  final static int emitZipkinBatchOverhead = 22;
+  final static int emitBatchOverhead = 22;


this might be a different number, because it includes the name of the struct

It seems that is 56 but it should be verified by someone.

yurishkuro · 2017-04-20T23:40:24Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

@@ -85,14 +92,20 @@ int getSizeOfSerializedSpan(Span span) throws SenderException {
   */
  @Override
  public int append(Span span) throws SenderException {
-    int spanSize = getSizeOfSerializedSpan(span);
+    if (process == null) {


nit: as far as I can tell, it's not used until the call to emitBatch, so I would (a) move this to a function and (b) inline it

emitBatch() is in Sender.flush(). Problem is that flush operates on thrift spans and I need access to tracer via Jaeger span.

Tracer tags should not change over time, therefore null check.

I just realized, there's another issue here. The previous Zipkin based code was able to compute the cumulative size of the message incrementally by sizing each span and adding to the overhead constant. But in jaeger.thrift model we have another variable, the process tags. Good news is we do not allow process tags to be changed post-construction, so we can pre-calculate their thrift size. But the overall calculation is getting more complex because Compact encoding uses varint encoding for things like the size of collections. So we need to be careful with the max-overhead constant. Ideally there should be a unit test to ensure that the final serialized buffer size does not exceed 65000, or it may be dropped by the agent.

see 5c65b9b

yurishkuro · 2017-04-20T23:54:41Z

jaeger-core/src/test/java/com/uber/jaeger/senders/UDPSenderTest.java

@@ -85,7 +87,7 @@ public void tearDown() throws Exception {
    reporter.close();
  }

-  @Test(expected = SenderException.class)
+  @Test


why doesn't this throw exception anymore?

I have to move jaegerSpan.log(msg, new Object()); into for cycle to thow it.

yurishkuro · 2017-04-20T23:55:57Z

jaeger-core/src/test/java/com/uber/jaeger/senders/UDPSenderTest.java

-    assertEquals(context.getParentID(), actualSpan.getParent_id());
-    assertEquals(expectedSpan.getOperationName(), actualSpan.getName());
+    com.uber.jaeger.thriftjava.Span actualSpan = spans.get(0);
+    assertEquals(expectedSpan.context().getTraceID(), actualSpan.getTraceIdLow());


please add a check for TraceIdHigh

added assertEquals(0, actualSpan.getTraceIdHigh());

yurishkuro · 2017-04-20T23:57:36Z

jaeger-jaxrs2/src/test/java/com/uber/jaeger/filters/jaxrs2/ServerFilterTest.java

@@ -97,8 +101,8 @@ public void filter() throws Exception {
    Span span = spans.get(0);
    Map<String, Object> tags = span.getTags();

-    assertTrue(span.isRPC() && !span.isRPCClient());
-    assertEquals(source, span.getPeer().getService_name());
+    assertTrue(ThriftSpanConverter.isRPC(span) && !ThriftSpanConverter.isRPCClient(span));


maybe it's worth leaving these helper methods on the Span, they are kind of used all over the place.

(sigh, I miss Scala)

codefromthecrypt · 2017-04-21T00:14:23Z

Can always write tests in any language.. even kotlin! :D

pavolloffay · 2017-04-22T08:57:27Z

This should be ready for the final review.

vprithvi · 2017-04-24T21:50:33Z

jaeger-core/src/main/java/com/uber/jaeger/Reference.java

+ */
+public class Reference {
+
+    private final SpanContext spanContext;


I prefer that we use lombok annotations to cut out boiler plate on new classes.
See https://projectlombok.org/features/Value.html

+1 I have used @Getter

I think we can use @Value and remove the constructor as well (we also gain a toString/Hashcode/Equals by doing that) .

vprithvi · 2017-04-24T22:03:12Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

@@ -21,6 +21,17 @@
 */
 package com.uber.jaeger;

+import java.io.InputStream;


I prefer that you don't reorder diffs in this commit. If it's difficult to undo, we can let it be and address later with #147

@vprithvi I have imported https://raw.githubusercontent.com/google/styleguide/gh-pages/intellij-java-google-style.xml and run optimize imports on the whole project. It produces a massive diff https://paste.fedoraproject.org/paste/ZSJs8G3jE~VExhSMKHwNuF5M1UNdIGYhyRLivL9gydE=.

It is inconvenient to go through 22 files and change that manually.

vprithvi · 2017-04-24T22:27:17Z

jaeger-jaxrs2/src/test/java/com/uber/jaeger/filters/jaxrs2/ServerFilterTest.java

-    assertTrue(span.isRPC() && !span.isRPCClient());
-    assertEquals(source, span.getPeer().getService_name());
+    assertEquals(method, span.getOperationName());
+    assertEquals(Tags.SPAN_KIND_SERVER, tags.get(Tags.SPAN_KIND.getKey()));


Could you also add an assertion for the service name?

I would have to change InMemoryReporter to hold tracer tags. Better is to test in in TracerTagsTest

vprithvi · 2017-04-24T22:28:38Z

jaeger-zipkin/src/main/java/com/uber/jaeger/senders/zipkin/ThriftSpanConverter.java

-        componentName = span.getLocalComponent().getBytes(UTF_8);
+      Object componentTag = tags.get(Tags.COMPONENT.getKey());
+      if (componentTag instanceof String) {
+        componentName = componentTag.toString().getBytes();


nit: Add the encoding for getBytes()

vprithvi · 2017-04-24T22:34:53Z

jaeger-zipkin/src/main/java/com/uber/jaeger/senders/zipkin/ThriftSpanConverter.java

+   */
+  public static Endpoint extractPeerEndpoint(Map<String, Object> tags) {
+    Object tagValue = tags.get(Tags.PEER_HOST_IPV4.getKey());
+    Endpoint peerEndpoint = null;


You could use zipkin.Endpoint#builder to make this neater.

I have refactored, now it looks much cleaner.

pavolloffay · 2017-04-25T10:46:49Z

ignore, deleted.

pavolloffay · 2017-04-27T13:04:19Z

@yurishkuro @vprithvi what is the status of this? Can we merge this?

vprithvi · 2017-04-27T13:31:50Z

Apart from that one nit, this looks good to me.
Ideally, I'd like to see the check style changes make it to the master before this, but we can move forward with this if it's a blocker for something else.

pavolloffay · 2017-04-27T15:06:53Z

@vprithvi removed @Getter and used @Value in Reference class.

About checkstyle: It would be easier for me to get this in and then apply checkstyle globally then do a rebase etc.

yurishkuro · 2017-04-27T15:26:06Z

@black-adder could you please review? The CI run looks odd to me, there's no matrix, I don't see a crossdock run, so not clear if end-to-end test has been executed.

black-adder · 2017-04-27T15:30:06Z

I'm gonna do a quick PR to add some endtoend tests for the java client. Once I land that, I'll rebase this to make sure endtoend works and then we can land it. Gimme an hour.

pavolloffay · 2017-04-27T17:03:53Z

rebased CI passed

yurishkuro · 2017-04-27T20:46:52Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

@@ -305,7 +327,8 @@ boolean isRPCServer() {
              startTimeMicroseconds,
              startTimeNanoTicks,
              computeDurationViaNanoTicks,
-              tags);
+              tags,
+              references);


one concern I have here is that we're duplicating the chid-of reference by keeping it explicitly as well we recording it implicitly in the parent_id. Strictly speaking in OpenTracing the parent_id is redundant, but we kept it (a) for efficiency since 99% of spans have a simple child-of relationship to the parent that we can represent with a single number instead of a Reference struct, and (b) to main our legacy zipkin-style wire format that includes parent ID (even though with zipkinSharedRPCSpan=false we completely ignore the parent_id on the wire).

On the other hand, in the UI data model we abolished the parent_id and represent everything with References, to keep it normalized. So when we keep this reference here, the code in the backend will create two identical references for the UI model (https://github.com/uber/jaeger/blob/master/model/converter/json/from_domain.go#L87).

We can either fix the backend code to dedupe those, but we could also exclude child-of reference here since it's redundant and only increases the payload.

This is an interesting topic, so parentId in thrift model should be set only if reference is childOf https://github.com/uber/jaeger/blob/master/model/converter/json/from_domain.go#L82

What if there are multiple childOf references? Which one to choose? First one/second...? Inject operation is also affected.

What if there is only one followsFrom/whatEverFrom. Should it be this set in thrift as parent. Should it be injected?

That's a bit of a grey area, given that Jaeger UI doesn't support arbitrary references today. My thoughts are:

if you have child-of within the same trace, then remove that reference and populate parent_id instead

if you have more than one child-of, use the first for parent_id, keep others are references

if you don't have child-of, but have follows-from in the same trace, then still populate parent_id, but keep the reference (this is a bit weird)

if you have reference to a different trace ID, do not populate parent_id, keep it as a reference

This sounds fairly convoluted, I am open to suggestions. We can implement just the first point for now and punt on the rest, which is probably what we've done in other clients so far.

Does the parent_id offer that much of a benefit, to warrant this processing in the client? Seems like it would be easier just to use the references.

If the parent_id is required for the UI currently, then couldn't this logic be implemented in the server, so that once the UI no longer requires it, it is simply a case of changing the logic in one place?

I wish we didn't have to maintain parent_id on the clients in the first place. It's only needed for compatibility with Zipkin's single span per RPC model that we still optionally support.

I think I'm ok with keeping both parent_id & child_of reference and just adding a sanitizer to the backend to normalize the representation.

Thrift Span model would be cleaner without a direct parentId field. If the parentId has been designed to save a little bit of payload then it should be used.

I think it should be only used to represent childOf relationship. Otherwise, it's ambiguous.

What if we establish a convention that parentId (in thrift span) should be used only when there is one parent as childOf. Otherwise, use only list of references. Thoughts?

What traceId should be used in a newly created span when there are references from different traces?

Create new traceId as a "join" or make an assumption that childOf is "stronger" and newly created span should inherit traceId?

If parent_id only used to maintain compatibility with Zipkin's model (as mentioned by @yurishkuro) - then the other alternative is Zipkin's parent id is simply converted to a ChildOf reference - then the new model would be "pure" :)

I think @yurishkuro meant only parentId from SpanContext class which also affects context...

yurishkuro · 2017-04-27T20:47:16Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

@@ -163,19 +172,17 @@ public void close() {

    private String operationName = null;
    private long startTimeMicroseconds;
-    private SpanContext parent;
+    private List<Reference> references = new ArrayList<Reference>();


yurishkuro · 2017-04-27T20:48:35Z

jaeger-core/src/main/java/com/uber/jaeger/Tracer.java

    private final Map<String, Object> tags = new HashMap<String, Object>();
+    private final Map<String, String> baggage = new HashMap<String, String>();


this introduces a couple of inefficiencies, we're always allocating two collections even though the list of references could be empty (see my comment below about child-of vs. parent_id representation), and when there is only one parent its baggage can be used as is, without copying (baggage is supposed to be immutable).

PS - if you prefer, we can address these in the follow-up PRs, since this one is pretty large.

yurishkuro · 2017-04-27T20:54:05Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

-    udpClient = new Agent.Client(new TCompactProtocol(udpTransport));
-    maxSpanBytes = maxPacketSize - emitZipkinBatchOverhead;
-    spanBuffer = new ArrayList<Span>();
+    udpClient = new Agent.Client(new TBinaryProtocol(udpTransport));


I think we should continue using compact protocol. The agent has a port that accepts jaeger-compact and jaeger-binary. The Binary is only used by the Node.js client, since thriftrw we're using there does not support Compact.

Fine, I chose binary because it was used in Node, going to switch to compact.

yurishkuro

@pavolloffay could you rebase off master?

yurishkuro · 2017-05-01T17:38:57Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

    memoryTransport.reset();
    try {
-      span.write(new TCompactProtocol(memoryTransport));
+      span.write(new TCompactProtocol((memoryTransport)));


extraneous params

yurishkuro · 2017-05-01T17:41:59Z

jaeger-core/src/main/java/com/uber/jaeger/reporters/protocols/JaegerThriftSpanConverter.java

+  static List<SpanRef> buildReferences(List<Reference> references) {
+    List<SpanRef> thriftReferences = new ArrayList<SpanRef>(references.size());
+    for (Reference reference: references) {
+      SpanRefType thriftRefType = References.CHILD_OF.equals(reference.getType()) ? SpanRefType.CHILD_OF :


I would pass a spanContext and add this check, to reduce the side of the span message:

if (References.CHILD_OF.equals(reference.getType()) && spanContext.getTraceID() == reference.getTraceID() && spanContext.getParentId() == reference.getSpanID()) { continue; // skip child_of reference that's already represented by parentID }

yurishkuro · 2017-05-01T17:55:38Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

@@ -85,14 +92,20 @@ int getSizeOfSerializedSpan(Span span) throws SenderException {
   */
  @Override
  public int append(Span span) throws SenderException {
-    int spanSize = getSizeOfSerializedSpan(span);
+    if (process == null) {


I just realized, there's another issue here. The previous Zipkin based code was able to compute the cumulative size of the message incrementally by sizing each span and adding to the overhead constant. But in jaeger.thrift model we have another variable, the process tags. Good news is we do not allow process tags to be changed post-construction, so we can pre-calculate their thrift size. But the overall calculation is getting more complex because Compact encoding uses varint encoding for things like the size of collections. So we need to be careful with the max-overhead constant. Ideally there should be a unit test to ensure that the final serialized buffer size does not exceed 65000, or it may be dropped by the agent.

…g, zipkin endpoint creation refactoring

yurishkuro · 2017-05-02T15:25:35Z

@black-adder is doing a similar change in Go and we want to develop a test that guarantees that the sender never overflows 65,000bytes buffer size. We will port that test to Java afterwards.

black-adder · 2017-05-02T21:37:00Z

jaeger-core/src/main/java/com/uber/jaeger/senders/UDPSender.java

  private static final String defaultUDPSpanServerHost = "localhost";
-  private static final int defaultUDPSpanServerPort = 5775;
+  private static final int defaultUDPSpanServerPort = 6832;


Interesting... https://github.com/uber/jaeger/blob/master/cmd/agent/app/config.go#L127 shows that port 6832 is for the jaeger-binary protocol but we're using compactProtocol here. Not sure how the endtoend tests are passing.

pavolloffay mentioned this pull request Apr 20, 2017

WIP: Move to jaeger.thrift #139

Closed

pavolloffay commented Apr 20, 2017

View reviewed changes

pavolloffay changed the title ~~Use jaeger.thrift~~ WIP: Use jaeger.thrift Apr 20, 2017

pavolloffay force-pushed the logs-new-model branch from 40dc159 to a7ac35a Compare April 20, 2017 17:23

pavolloffay changed the title ~~WIP: Use jaeger.thrift~~ Use jaeger.thrift Apr 20, 2017

yurishkuro reviewed Apr 20, 2017

View reviewed changes

vprithvi reviewed Apr 24, 2017

View reviewed changes

pavolloffay mentioned this pull request Apr 25, 2017

Enable process level tags to be associated with the tracer #143

Merged

pavolloffay force-pushed the logs-new-model branch from 4b1dbd6 to 04a1a13 Compare April 27, 2017 16:51

black-adder approved these changes Apr 27, 2017

View reviewed changes

yurishkuro reviewed Apr 27, 2017

View reviewed changes

yurishkuro reviewed May 1, 2017

View reviewed changes

black-adder mentioned this pull request May 1, 2017

Build jaeger.SpanRef jaegertracing/jaeger-client-go#146

Merged

pavolloffay added 2 commits May 2, 2017 14:59

Use jaeger.thrift

33a8ce7

nove service name to sender

82a8956

pavolloffay added 18 commits May 2, 2017 14:59

Do not skip component tag

5b2f594

Remove localComponent from Span class

4a6af61

Move span convertion to Sender

9211289

Remove service name from UDPSender constructor

88ce792

Remove zipkin endpoint from Span and move it to ThriftConvertor

20399c7

SharedSpan option in Tracer for zipkin server compatibility

44662e6

Add tracer tags to Batch or zipkin span

544cd7d

Remove compact mapping tags to zipkin annotations

7de1817

Move ZipkinThriftConverter to jaeger-zipkin

6720a5a

Move inMemorySender to tests

48f9202

Fix UDPSender emitBatch tests/size

b064c75

trivial fixes in Tracer

9395801

Review comments, use lombook, test jaer tracer tags, getBytes encodin…

1a6168f

…g, zipkin endpoint creation refactoring

Use @value in Reference instead of @Getter

6cd90c9

Use TCompact protocol

25db00f

Define references as final

53bc6a0

remove duplicated parenthesis

5b50523

Add size of process tags to UDPSender

5c65b9b

pavolloffay force-pushed the logs-new-model branch from 11b83a8 to 5c65b9b Compare May 2, 2017 12:59

yurishkuro merged commit e947f19 into jaegertracing:master May 2, 2017

black-adder reviewed May 2, 2017

View reviewed changes

pavolloffay mentioned this pull request May 3, 2017

Multiple references clarification #161

Merged

pavolloffay mentioned this pull request May 10, 2019

Automatically generate changelog #629

Closed

		@@ -21,6 +21,11 @@
		*/
		package com.uber.jaeger.reporters.protocols;

		private final Map<String, Object> tags = new HashMap<String, Object>();
		private final Map<String, String> baggage = new HashMap<String, String>();

Use jaeger.thrift #142

Use jaeger.thrift #142

Conversation

pavolloffay commented Apr 20, 2017

codecov-io commented Apr 20, 2017 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavolloffay commented Apr 20, 2017

yurishkuro commented Apr 20, 2017

pavolloffay commented Apr 20, 2017

yurishkuro commented Apr 20, 2017

pavolloffay commented Apr 20, 2017

yurishkuro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codefromthecrypt commented Apr 21, 2017 via email

pavolloffay commented Apr 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavolloffay commented Apr 25, 2017 • edited Loading

pavolloffay commented Apr 27, 2017

vprithvi commented Apr 27, 2017

pavolloffay commented Apr 27, 2017

yurishkuro commented Apr 27, 2017

black-adder commented Apr 27, 2017

pavolloffay commented Apr 27, 2017

Choose a reason for hiding this comment

pavolloffay Apr 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavolloffay May 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yurishkuro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Apr 20, 2017 •

edited

Loading

pavolloffay commented Apr 25, 2017 •

edited

Loading

pavolloffay Apr 28, 2017 •

edited

Loading

pavolloffay May 2, 2017 •

edited

Loading