[Core] Extract Gherkin compatibility layer #1804

aslakhellesoy · 2019-10-14T21:53:17Z

We want to support both Gherkin 5 and Gherkin 8 + Cucumber Messages in the next major release of Cucumber-JVM.

aslakhellesoy · 2019-10-14T21:53:52Z

@mpkorstanje thanks for starting a branch for this. I've created a draft pull request so we have a place to discuss.

coveralls · 2019-10-14T22:02:56Z

Coverage increased (+0.1%) to 87.613% when pulling 8f56641 on prep-work-gherkin-8 into 2f76520 on master.

aslakhellesoy · 2019-10-15T14:18:46Z

I tried adding this to the cucumber-core pom:

        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>gherkin</artifactId>
            <version>5.2.0</version>
        </dependency>
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>gherkin</artifactId>
            <version>8.0.1-SNAPSHOT</version>
        </dependency>

Maven does not allow that, so I think we need to create a separate core module targetting gherkin 8

mpkorstanje · 2019-10-15T19:09:22Z

Maven does not allow that, so I think we need to create a separate core module targetting gherkin 8

Looks like the group id + artifact combination must be unique so we can only have 1 gherkin on the class path when using maven. Applied an exclusion to v5 in the calculator example and now it just works.

This should be sufficient for a spike-release.

mpkorstanje · 2019-10-15T19:34:27Z

examples/java-calculator/src/test/java/io/cucumber/examples/java/RunCucumberTest.java

@@ -5,7 +5,7 @@
 import org.junit.runner.RunWith;

 @RunWith(Cucumber.class)
-@CucumberOptions(plugin = {"json:target/cucumber-report.json"})
+@CucumberOptions()


TODO: Json plugin still uses gson.

mpkorstanje · 2019-10-15T19:37:21Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberFeatureParser.java

+    private static CucumberFeature parseGherkin5(URI path, String source) {
+        try {
+
+            Stream<Messages.Envelope> messages = Gherkin.fromStream(new ByteArrayInputStream(source.getBytes(UTF_8)));


This conversion back to stream is needed because we read the #encoding pragma in Encoding.java. Ideally this is supported by Gherkin. Or we deprecate and drop it.

mpkorstanje · 2019-10-15T19:38:00Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberFeatureParser.java

+            Stream<Messages.Envelope> messages = Gherkin.fromStream(new ByteArrayInputStream(source.getBytes(UTF_8)));
+
+            Parser<Messages.GherkinDocument.Builder> parser = new Parser<>(new GherkinDocumentBuilder());
+            Messages.GherkinDocument gherkinDocument = parser.parse(source).setUri(path.toString()).build();


Not sure where this URI goes but if it comes out again as string it might be useful. Would be better if this was a URI type object.

mpkorstanje · 2019-10-15T19:39:07Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberFeatureParser.java

+        return new PickleCompiler().compile(document, path.toString(), source)
+            .stream()
+            .map(pickle -> new Gherkin8CucumberPickle(pickle, path, document, dialect))
+            .collect(Collectors.toList());


We don't use the messages here because we need some info from the AST in cucumber-jvm this make it hard to use just the pickles.

mpkorstanje · 2019-10-15T19:40:09Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberPickle.java

+    @Override
+    public int getScenarioLine() {
+        List<Location> stepLocations = pickle.getLocationsList();
+        return stepLocations.get(stepLocations.size() - 1).getLine();


Is this still correct? I had to swap this in Gherkin8CucumberStep

Pickle steps coming from Examples rows have two locations - in this order:

index 0: The step

index 1: The table row

It's sort of a stack trace. The line at index 1 "calls" the line at index 0.

Example here: https://github.com/cucumber/cucumber/blob/158d617ff7b9b58621bc9c1c6929c1cd4dd0bcec/gherkin/testdata/good/scenario_outline.feature.pickles.ndjson#L18-L27

By always getting the last element we point to the table row line (for pickles from Examples) and the step line for regular scenarios.

I think that's what we want to report as it points people at the line they most likely need to fix.

Then I would appreciate a descriptive method to access the last line number. Perhaps we can call it pickleLine because it is the line that defines the pickle. It would remove one obstacle that keeps me from using plain pickles in Cucumber.

I like that idea. Just like we've talked about adding a GherkinDocumentsModel class to cucumber-messages, we could add a PickleModel class to cucumber-messages as well.

In short - some utility classes for getting interesting data out of those dumb protobuf structs.

Yes. Though I think utility classes are an anti-pattern when you own or can design the domain objects.

When ever you run into a pattern like:

Object dumb = ... String propertyA = dumb.propertyA(); String propertyB = SmartUtils.propertyB(dumb)

It's better to rewrite it to a facade and use the facade everywhere. E.g:

Object dumb = .... Smart smart = new Smart(dumb); String propertyA = smart.propertyA() String propertyB = smart.propertyB();

I think we’re after the same thing! This is basically the facade pattern.

We could provide different flavours of facades around protobuf messages. One could process a stream of historical messages (stored in an event store like database, heck could even be Kafka). This way we could generate more interesting data like historical trends for execution time, flakiness, failure rates or even lead times from new to passing. The computed data could be stored in the database (if the computation is time consuming. This could be implemented as streams and pipes, allowing for composition.

mpkorstanje · 2019-10-15T19:40:48Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberStep.java

+        if (dialect.getButKeywords().contains(keyWord)) {
+            return StepType.BUT;
+        }
+        throw new IllegalStateException("Keyword " + keyWord + " was neither given, when, then, and, but nor *");


Ideally this would come from the pickle.

mpkorstanje · 2019-10-15T19:41:05Z

gherkin8/src/main/java/io/cucumber/core/gherkin5/Gherkin8CucumberStep.java

+                });
+        }
+
+        return Stream.empty();


No inheritance. 😢

mpkorstanje · 2019-10-16T06:59:09Z

pom.xml

                        <dependency>
                            <groupId>io.cucumber</groupId>
                            <artifactId>gherkin</artifactId>
-                            <version>${gherkin.version}</version>
+                            <version>8.0.1-SNAPSHOT</version>


TODO: Make this a property for easier maintaince.

aslakhellesoy · 2019-10-16T09:38:36Z

The TestSourcesModel class is tightly coupled to Gherkin5, and several formatters depend on it. I wonder if we can refactor it to depend on the cucumber-gherkin module instead...

aslakhellesoy · 2019-10-16T09:46:24Z

HTMLFormatter, JSONFormatter, PrettyFormatter and TimelineFormatter all import gherkin.* as well. Aaaaaaargh!

mpkorstanje · 2019-10-16T09:47:59Z

Aaaaaaargh!

My reaction too. But we can leave those alone and implement the message formatter.

aslakhellesoy · 2019-10-16T10:00:48Z

What do you mean by implementing the message formatter?

Currently, cucumber-core depends on cucumber-gherkin5. If I understand correctly, the idea is that cucumber-core should only depend on cucumber-gherkin, and use ServiceLoader to load either cucumber-gherkin5 or cucumber-gherkin8 at runtime.

So we need to remove the cucumber-gherkin5 dependcency from cucumber-core.

If we're going to leave all those formatters unchanged, perhaps we should move them into cucumber-gherkin5?

mpkorstanje · 2019-10-16T10:04:23Z

The idea was to ship with Gherkin 5 and allow people to test drive the protobuf message formatter with Gherkin 8 without getting into woods of fixing the existing formatters.

aslakhellesoy · 2019-10-16T10:05:19Z

I agree with that goal. Do you agree we should move everything that depends on gherkin5 into the new cucumber-gherkin5 module?

mpkorstanje · 2019-10-16T10:07:32Z

No. That would be allot of work all the tests for the formatters are integration tests.

aslakhellesoy · 2019-10-16T10:08:29Z

So how do you suggest we break the hard dependency on Gherkin5 from cucumber-core so that Gherkin8 can be loaded at runtime?

mpkorstanje · 2019-10-16T10:14:36Z

Like this:

cucumber-jvm/examples/java-calculator/pom.xml

Line 43 in 302b369

<artifactId>cucumber-gherkin5</artifactId>

And tell people not to use any formatters at runtime.

aslakhellesoy · 2019-10-16T10:45:24Z

Aha!

mpkorstanje · 2019-10-16T22:56:36Z

Been thinking about this problem some more. And I think we've been ignoring the elephant in the room.

People who write plugins (us included) will need an easy way to map pickles back to AST nodes - the whole reason TestSourcesModel exsists. In essence something like GherkinDocument.getStuffAtLine(int line). This API should be provided by Cucumber JVM/Gherkin but neither Gherkin 5 nor Gherkin 8 provide anything like it. A stable representation of the GherkinDocument decoupled from any parsing or messaging concerns should also make our lives a bit easier in terms of migration and upgrades.

You made the suggestion to use CucumberFeature in all plugins. I would rather not do that. CucumberFeature is very focused at facilitating the internals of Cucumber and I think most of its functionality belongs in either Pickle or GherkinDocument. However we can apply the same trick to GherkinDocument. Gherkin 8 is a superset of Gherkin 5 after all.

This approach has some other advantage too. You've mentioned in the past the desire to support other formats for feature files gherkin. A stable representation will allow multiple parser implementations.

So in summary:

Instead of implementing CucumberFeature for Gherkin5 and Gherkin8 we implement GherkinDocument for Gherkin5 and Gherkin8 and use that everywhere.
We enrich GherkinDocument with methods to make mapping pickles to AST nodes easy.
Gherkin becomes a multi-module project with gherkin, gherkin5 and gherkin8 modules.

aslakhellesoy · 2019-10-16T23:51:44Z

This all sounds good to me. Not sure when I suggested to use CucumberFeature in all plugins?

As you know I want to decouple Cucumber even more from Gherkin and "features". I intend to start implementing a Markdown->Pickle compiler soon, and maybe even one for Excel. At this point, the Gherkin and "feature" abstractions break down. It's ok for formatters to depend on the input format, so they can render results on top of the input, which requires custom mapping from pickles back to the input model. Cucumber Core shouldn't know about input formats - it should only use pickles for execution and reporting.

I think of it as this pipeline (note how it's input format agnostic - no gherkin assumptions):

           similar                                 +--------+
     +---------------------------------------------+ report |
     |                                             |document|
     |                                             +----^---+
     |                                                  |
     |                                                  |
     |                     all messages                 |
     |                     (source, ast, pickles)  +----+----+
     |                            +---------------->formatter|
     |                            |                +---^-----+
+----+---+      +------+      +---+----+               |
|document+------>parser+------>messages|               | result messages
+--------+      +------+      +---+----+               |
                                  |                    |
                                  |                +---+----+
                                  +---------------->cucumber|
                                pickle messages    +--------+

If I understand you correctly, you're suggesting implementing a query API for each input AST to make it easier to look up AST nodes from pickles. I think that makes a lot of sense. @vincent-psarga and I actually implemented this logic in Go when we ported the JSON formatter. This could easily be refactored and decoupled from the JSON parts, and then we could move it to the cucumber-messages module and port it to the other languages.

How does this sound?

mpkorstanje · 2019-10-17T00:32:24Z

Sound in theory but I don't think pickles in their current state contain sufficient information to support both execution and reporting.

I also think we'll need a Pickle tree as part of this.

And I think if we do support multiple input formats reporters need to be agnostic of the input as well. Currently I don't see how that is supported.

aslakhellesoy · 2019-10-17T08:26:20Z

I think it will be quite difficult to implement formatters that are agnostic of the input format and procude a report that is similar to the input format. I'm not convinced about the hierarchy thing - I have a slightly different vision. Cucumber-React / HTML Formatter is able to display a hierarchy - not because we have hierarchy information in the pickles, but because it traverses the GherkinDocument AST.

I don't know much about text-to-speech engines, but I imagine they have different implementations for different spoken languages. You can't feed French text to a Russian engine and expect good results. For the same reason I think a Gherkin pretty formatter (for example) can only pretty-print Gherkin, but not Markdown or Excel. Unless we come up with a montrosity abstraction for representing all possible document formats in the world.

I think it's more useful to group formatters in two categories:

IDA: Input document agnostic
IDD: Input document dependent

IDA formatters only need Pickle + TestResult to produce a report. Examples are progress, junit and rerun.

IDD formatters need AST + Pickle + TestResult to produce a report. Examples are pretty, html, json.

The AST is different for each input format:

GherkinDocument
MarkdownDocument
ExcelDocument

Each IDD formatter will only work with one kind of input document. The Gherkin pretty formatter will not work with Markdown and Excel for example (like text-to-speech engines - it only works with one language).

As you've pointed out, looking up AST nodes from pickles is complicated, because the AST has to be traversed first to build a lookup table. This is what TestSourcesModel does.

I think that concept is good - we just need to change their name so we don't give the impression that this is a universal model for all kinds input documents:

GherkinDocumentsModel
MarkdownDocumentsModel
ExcelDocumentsModel

I imagine at runtime we'd have a single instance of e.g. GherkinDocumentsModel which wraps all the GherkinDocument objects and provides a suitable lookup API for IDD Gherkin formatters.

mpkorstanje · 2019-10-17T12:35:30Z

core/src/main/java/io/cucumber/core/plugin/ProtobufFormatterAdapter.java

+
+    public ProtobufFormatterAdapter(OutputStream out) {
+        try {
+            Class<EventListener> delegateClass = (Class<EventListener>) getClass().getClassLoader().loadClass(PROTOBUF_FORMATTER);


For now this is okay.

But we should upgrade the plugin system to make registering plugins via SPI possible. Then the protobuf formatter could live in its own module.

Completely agree - I added it to the gherkin8 module out of pure laziness since I think we're still in spike mode. Let's do that before we merge this.

mpkorstanje · 2019-10-17T12:39:28Z

gherkin8/src/main/java/io/cucumber/core/gherkin8/formatter/ProtobufFormatter.java

+
+import static java.util.Collections.singletonList;
+
+public class ProtobufFormatter implements EventListener {


Ideally the ProtobufFormatter would be living in the core module. But can't because gherking 5 and 8 have clashing artifact names. Do we want to resolve this?

I think it’s pragmatic to keep it here for now. We can move it once we get rid of gherkin 5.

I've resolved it by moving the protobuf formatter to it's own module. It only has a dependency on cucumber-plugin and a shaded dependency on Gherkin 8.

mpkorstanje · 2019-10-19T11:44:29Z

I just checked out the contents of cucumber-messages. It currently also contains "Cucumber-Engine Messages". Consumers don't need to know about the Cucumber Engine. So I think we should provide split cucumber-messages into a part for the engine and a part for the reporters.

This will make it easier for people who want to consume reporting out to use the library to use it because it only contains what they'll need.

Ideally we also put the smart delegates that use the message in a separate library (no smarts in cucumber-messages) so we can evolve the smarts at a different pace from the protocol. This would separate the API from the serialization format which would be a good split because they've got separate concerns to deal with.

And if we decided for some reason that protobuff doesn't work out we can switch to json, xml or some other format while keeping the same API.

mpkorstanje · 2019-11-23T20:43:52Z

We need to fix a few things here:

resources in google should be relocated (this is a problem in cucumber-messages, it's missing a relocation pattern)
cucumber-messages should not be shaded into gherkin (this is a problem in gherkin, it's missing explicit inclusion sets.

aslakhellesoy · 2019-11-23T22:00:36Z

I think we can safely exclude the .proto files from the jar. I don’t think they are required at runtime.

We use https://github.com/cucumber/cucumber/blob/master/.templates/java/scripts/check-jar.sh to verify jar contents during a release.

I suggest we do 2 things:

Run this script as part of the build tobdiscover this before release (change default.mk)
Fail if any io.cucumber.* classes outside this module are included in the shades jar

aslakhellesoy · 2019-11-23T22:02:14Z

We can use xmlstarlet to extract this module’s package, assuming it coincides with its classes’ package (it should).

aslakhellesoy · 2019-11-24T00:04:50Z

Regarding your suggestion to split up messages in smaller chunks. I want to do that eventually, but not until it's more stable. Some separation of concerns can be achieved in the single file by nesting related messages. The GherkinDocument AST for example is organised like that.

There has been a fair amount of flux in the message definitions lately, and I think that will continue until we have some feedback from real users.

When it settles down a bit and has a track record we can clean it up and separate it. For now I think it is more important to make changes more easily.

mpkorstanje · 2019-11-24T11:21:25Z

What should be possible now is the following:

- Gherkin 5 + Json Formatter + Protobuf - Rule keyword ==> Works 
- Gherkin 8 + Json Formatter + Protobuf - Rule keyword ==> Works
- Gherkin 8 - Json Formatter + Protobuf + Rule keyword ==> Works

In my mind this meets the criteria for a smooth migration. People can setup a reporting tool that consumes protobuf. Then drop the json formatter and switch to gherkin 8 to start using the rule keyword.

When it settles down a bit and has a track record we can clean it up and separate it. For now I think it is more important to make changes more easily.

Fair enough.

If possible I'd like to restrict the cucumber-messges dependency to cucumber-protobuf-plugin for now. Trying to integrate it in Cucumber is another Yak.

If anything I don't think piggy backing messages onto regular events is the way to go. Ideally we'd create a separate event that contains only the Message. But I would rather not commit to any specific implementation right now.

mpkorstanje · 2019-11-24T12:18:59Z

Fixed a few formatters. Only the PrettyFormatter left to fix.

The JSON and HTML are lost causes as expected.

mpkorstanje · 2019-11-24T12:36:27Z

A think to consider: The protbuf formatter prints either ndjson or protobufs. Perhaps we should rename it to the cucumber messages formatter? That we it describe the protocol rather then the serialization format by the protocol.

mpkorstanje · 2019-11-24T17:15:07Z

Notes to self:

Abstract pickle tree to classes for containers and pickles only.
JUnit5 testId fragments depend on node type so include that (or use the keyword?).
Remove getPickleAt (should be part of the tree).
Rename or remove Cucumber* prefix in io.cucumber.core.gherkin.
Clean up api of io.cucumber.core.gherkin.
Rewrite Pretty formatter to use the pickle tree abstraction.
Rewrite Pretty formatter to print the tree-path to each pickle (keyword + text)
Make pretty formatter smart and only print the path if the previous pickle didn't print it yet.
Include embeddings as [123456 bytes image/png]
Rename keyword+name to keyword+???, something more descriptive anyway.
Consider moving formatters to individual dependencies (for easier shading, ect).
Consider some SPI implementation for Plugins

aslakhellesoy · 2019-11-24T21:50:09Z

On our last call we discussed how to implement new message-based formatters. Did we all agree we'll write them in the monorepo, using a shared test suite similar to gherkin's. We could use fake-cucumber to generate messages.

So I assume the new pretty formatter will go into the monorepo? There are a few there already, so should be relatively easy to parrot the design pattern. Essentially a (InputStream in, OutputStream out) function that reads messages from in and writes something else to out.

Shall we start with a simple one that essentially just prints pickles? We could use cucumber-query to look up the keyword. I think this would be good enough for 90% of our users.

Where do you think the pickle tree abstraction belongs? Inside cucumber-query perhaps?

mpkorstanje · 2019-11-25T01:39:40Z

Fixing the TestNG and JUnit formatter came down to changing one small thing. We'll still have to lift them out but they're no longer in the way of a release. This would be a change we can do in v5.x rather then a v5.0. So one less Yak to shave for now.

There are a few implicit assumptions around pretty formatter. Before committing to polyglot project and deal with the input/ouputstream stuff. I'd like to see what the output actually looks like and how it behaves during parallel execution and if we can reasonably work around that.

Currently Cucumber JVM has reasonable system for dealing with messages that occur out of order. We lose that mechanism if we switch to protobufs. If it all does work out it should be easy to lift the pretty formatter. The messages/events we need for the pretty formatter have a 1-1 correspondence.

mpkorstanje · 2019-11-25T01:46:50Z

Where do you think the pickle tree abstraction belongs? Inside cucumber-query perhaps?

Yeah we'd need something like cucumberQuery.getAncestors(pickle) that returns a list of AST elements [Feature, Rule, Scenario, Example Section, Example]. So we can get the key word and title of each. But we'll see it when we get there.

mpkorstanje · 2019-12-04T20:26:02Z

We use https://github.com/cucumber/cucumber/blob/master/.templates/java/scripts/check-jar.sh to verify jar contents during a release.

Done.

cucumber/common#819

mpkorstanje · 2019-12-06T15:58:46Z

I think we have something mergeable now. Only 5 things remain:

Check the use of setHookId in TestStep.createTestStep
Finish message protocol
Release version of Messages
Release version of Gherkin
Integration tests for message formatter.

And maybe write a proper commit message for this whole thing. Should include a link to:

https://github.com/cucumber/cucumber/tree/master/cucumber-messages

Gherkin 6 introduced the `Rule` keyword and a new AST structure. This poses several problems. 1. Cucumber-JVM is closely tied to the Pickle structure of Gherkin 5. 2. The HTML and JSON formatters use the Gherkin 5 parser. 3. The JSON formatter is the defacto output standard for third party tools. 4. There is no schema for the JSON formatters output. To phase out the JSON formatter we'll need an alternative. This alternative is the `message` formatter. This plugin will write the output of Cucumbers execution to protobuf or ndjson file using the schema defined in `cucumber-messages`. Because `cucumber-messages` for Gherkin can only be generated by Gherkin 8 we need a way to run both Gherkin 5 and Gherkin 8 next to each other. By extracting a compatibility layer we can use both Gherkin 5 and Gherkin 8.

Broken by #1804. While covered by unit tests, the unit tests were broken by a change in the way feature identifiers were parsed. When parsing a feature path relative paths are expanded to full file uris. This resulted in the uri of the pickle not matching the uri provided by the test.

Broken by #1804. While covered by unit tests, the unit tests were broken by a change in the way feature identifiers were parsed. When parsing a feature path relative paths are expanded to full file uris. This resulted in the uri of the pickle not matching the uri provided by the test. Fixes: #1980

mpkorstanje reviewed Oct 15, 2019

View reviewed changes

mpkorstanje reviewed Oct 16, 2019

View reviewed changes

mpkorstanje reviewed Oct 17, 2019

View reviewed changes

mpkorstanje added this to the 5.0.0 milestone Nov 29, 2019

mpkorstanje changed the title ~~Gherkin 8 support~~ [Core] Gherkin 8 support Dec 6, 2019

mpkorstanje force-pushed the prep-work-gherkin-8 branch from bf5ed43 to 11fce15 Compare December 12, 2019 17:47

mpkorstanje changed the title ~~[Core] Gherkin 8 support~~ [Core] Extract Gherkin compatibility layer Dec 12, 2019

mpkorstanje force-pushed the prep-work-gherkin-8 branch from 11fce15 to 8f56641 Compare December 13, 2019 13:56

mpkorstanje marked this pull request as ready for review December 13, 2019 14:05

mpkorstanje merged commit cee8eb2 into master Dec 13, 2019

mpkorstanje deleted the prep-work-gherkin-8 branch December 13, 2019 14:06

davidjgoss mentioned this pull request Dec 20, 2019

[Core] Include default gherkin version in version.properties #1847

Merged

6 tasks

mpkorstanje mentioned this pull request May 29, 2020

[Core] Fix line filter for scenario outlines #1981

Merged

3 tasks


		import static java.util.Collections.singletonList;

		public class ProtobufFormatter implements EventListener {

[Core] Extract Gherkin compatibility layer #1804

[Core] Extract Gherkin compatibility layer #1804

Conversation

aslakhellesoy commented Oct 14, 2019

aslakhellesoy commented Oct 14, 2019

coveralls commented Oct 14, 2019 • edited Loading

aslakhellesoy commented Oct 15, 2019

mpkorstanje commented Oct 15, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpkorstanje Oct 15, 2019 • 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

mpkorstanje Oct 18, 2019 • 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

mpkorstanje Oct 16, 2019 • edited Loading

Choose a reason for hiding this comment

aslakhellesoy commented Oct 16, 2019

aslakhellesoy commented Oct 16, 2019

mpkorstanje commented Oct 16, 2019

aslakhellesoy commented Oct 16, 2019

mpkorstanje commented Oct 16, 2019

aslakhellesoy commented Oct 16, 2019

mpkorstanje commented Oct 16, 2019

aslakhellesoy commented Oct 16, 2019

mpkorstanje commented Oct 16, 2019

aslakhellesoy commented Oct 16, 2019

mpkorstanje commented Oct 16, 2019 • edited Loading

aslakhellesoy commented Oct 16, 2019 • edited Loading

mpkorstanje commented Oct 17, 2019

aslakhellesoy commented Oct 17, 2019 • 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

mpkorstanje commented Oct 19, 2019 • edited Loading

mpkorstanje commented Nov 23, 2019

aslakhellesoy commented Nov 23, 2019

aslakhellesoy commented Nov 23, 2019

aslakhellesoy commented Nov 24, 2019

mpkorstanje commented Nov 24, 2019 • edited Loading

mpkorstanje commented Nov 24, 2019

mpkorstanje commented Nov 24, 2019 • edited Loading

mpkorstanje commented Nov 24, 2019 • edited Loading

aslakhellesoy commented Nov 24, 2019

mpkorstanje commented Nov 25, 2019 • edited Loading

mpkorstanje commented Nov 25, 2019 • edited Loading

mpkorstanje commented Dec 4, 2019

mpkorstanje commented Dec 6, 2019 • edited Loading

coveralls commented Oct 14, 2019 •

edited

Loading

mpkorstanje Oct 15, 2019 •

edited

Loading

mpkorstanje Oct 18, 2019 •

edited

Loading

mpkorstanje Oct 16, 2019 •

edited

Loading

mpkorstanje commented Oct 16, 2019 •

edited

Loading

aslakhellesoy commented Oct 16, 2019 •

edited

Loading

aslakhellesoy commented Oct 17, 2019 •

edited

Loading

mpkorstanje commented Oct 19, 2019 •

edited

Loading

mpkorstanje commented Nov 24, 2019 •

edited

Loading

mpkorstanje commented Nov 24, 2019 •

edited

Loading

mpkorstanje commented Nov 24, 2019 •

edited

Loading

mpkorstanje commented Nov 25, 2019 •

edited

Loading

mpkorstanje commented Nov 25, 2019 •

edited

Loading

mpkorstanje commented Dec 6, 2019 •

edited

Loading