Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BEAM-5107] Support ES-6.x for ElasticsearchIO #6211

Merged
merged 1 commit into from Sep 6, 2018

Conversation

Projects
None yet
3 participants
@dattran-vn01
Copy link

dattran-vn01 commented Aug 12, 2018

This PR supports ES 6.x for ElasticsearchIO.
Right now ElasticsearchIO only supports 2.x-5.x

Hello @timrobertson100, please help to review it. Thank you.

Follow this checklist to help us incorporate your contribution quickly and easily:

  • Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Post-Commit Tests Status (on master branch)

Lang SDK Apex Dataflow Flink Gearpump Samza Spark
Go Build Status --- --- --- --- --- ---
Java Build Status Build Status Build Status Build Status Build Status Build Status Build Status
Python Build Status --- Build Status
Build Status
--- --- --- ---

@dattran-vn01 dattran-vn01 changed the title BEAM-5107 Support-ES-6.x for ElasticsearchIO [BEAM-5107] Support-ES-6.x for ElasticsearchIO Aug 12, 2018

@dattran-vn01 dattran-vn01 changed the title [BEAM-5107] Support-ES-6.x for ElasticsearchIO [BEAM-5107] Support ES-6.x for ElasticsearchIO Aug 12, 2018

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 12, 2018

Thanks @dattran-vn01

Do you think it is possible to add a test to demonstrate it does work with ES6 please?

Looking at the commented out test it implies that the full addressing doesn't work. At a minimum I'd suggest that needs documented in the JDoc for the ElasticsearchIO.

Are you aware that there is WIP for an ES6 IO on https://issues.apache.org/jira/browse/BEAM-3199 - it looks pretty complete and is already used by one person in production, but IIRC doesn't have tests. Have you any thoughts on whether we should enable partial support for ES6 as I think you do here (addressing not working) or push for the full support with BEAM-3199?

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Aug 12, 2018

Thank you @timrobertson100. I did not know that there is WIP BEAM-3199.
I prefer to go with my simple approach because it keeps one production module to avoid confusion for the users.
I will add one something in the JDoc for the full addressing and add new elasticsearch-tests-6 module to demonstrate it does work with ES6.

If you agree with my approach, I will update my PR tomorrow. We are also using this approach in production.

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 12, 2018

Thanks @dattran-vn01

I've commented on the Jira so design decisions taken will be easily searchable/traceable.

I do agree this is a good approach, although I don't know what will happen when you try and have an embedded ES6 on the classpath for a unit test. I've offered an alternative approach on the Jira should that cause issue and we should try and get agreement from others to go for a pragmatic approach.

As for the code you provided, I've only scanned quickly but first impressions were very favourable. Thanks again.

(Please be aware that I am not a committer, so I can't merge it. I can hopefully help speed up that process though)


def jna_version = "4.1.0"
def log4j_version = "2.6.2"
def elastic_search_version = "6.3.2"

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

Copy from elasticsearch-tests-5 and change here

testCompile project(path: ":beam-sdks-java-io-elasticsearch-tests-common", configuration: "shadowTest")
testCompile "org.elasticsearch.test:framework:$elastic_search_version"
testCompile "org.elasticsearch.plugin:transport-netty4-client:$elastic_search_version"
testCompile "com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.5.2"

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

Copy from elasticsearch-tests-5 and change here

@@ -0,0 +1,24 @@
#!/bin/sh

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

Copy from elasticsearch-tests-5

}

@Test
public void testWriteFullAddressing() throws Exception {

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

This test still works in ES 6


@SuppressWarnings("EmptyMethod")
public static void checkJarHell(Consumer<String> output) {
System.out.println(

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

Add one argurement to checkJarHell. It's different from ES 5.x

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

yes but printing it is unnecessary. please remove the System.out.println

@@ -133,8 +133,7 @@ void testReadWithQuery() throws Exception {
+ " \"query\": {\n"
+ " \"match\" : {\n"
+ " \"scientist\" : {\n"
+ " \"query\" : \"Einstein\",\n"
+ " \"type\" : \"boolean\"\n"
+ " \"query\" : \"Einstein\"\n"

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 13, 2018

Author

Remove to support both ES 5&6

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

Nice! I see through the gree UTests that the test still work in ES5 and works in ES6. Thanks

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 13, 2018

Thanks @dattran-vn01
I’ll review this within the next 24hrs unless someone gets there first

#Create an ELK (Elasticsearch Logstash Kibana) container for ES v2.4 and compatible Logstash and Kibana versions,
#bind then on host ports, allow shell access to container and mount current directory on /home/$USER inside the container

docker create -p 5601:5601 -p 9200:9200 -p 5044:5044 -p 5000:5000 -p 9300:9300 -it -v $(pwd):/home/$USER/ --name elk-2.4 sebp/elk:es240_l240_k460

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 13, 2018

Contributor

I think this looks wrong as it would start a 2.4.0 Elasticsearch server wouldn't it?
Should it perhaps be more along the lines of this?

sudo docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -it -e LOGSTASH_START=0 -e KIBANA_START=0 --name elk-6.3.2 sebp/elk:632

I notice that the ES5 is also wrong in Github and should be more along the lines of the following I think:

sudo docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -it -e LOGSTASH_START=0 -e KIBANA_START=0 --name elk-5.4.3 sebp/elk:543

If you agree, could you correct ES5 as well in this PR please?

}
}
assertEquals("Wrong number of empty splits", expectedNumSources, nonEmptySplits);
}

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 13, 2018

Contributor

I think this looks like a direct copy from ES5. If so, would it be possible to move to the common utility to avoid repetition?

"There are too many empty splits, parallelism is sub-optimal",
emptySplits,
lessThan((int) (ACCEPTABLE_EMPTY_SPLITS_PERCENTAGE * splits.size())));
}

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 13, 2018

Contributor

As above - could it be moved to the common util to avoid repetition do you think?

@@ -374,6 +373,9 @@ public String apply(JsonNode input) {
* Tests that documents are dynamically routed to different types and not the type that is given
* in the configuration. Documents should be routed to the a type of type_0 or type_1 using a
* modulo approach of the explicit id.
*
* <p>This test does not work with ES 6 because ES 6 does not allow one mapping has more than 1

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 13, 2018

Contributor

Nit:

<p>This test does not work with ES 6 because multiple type support within an index was removed.
@timrobertson100
Copy link
Contributor

timrobertson100 left a comment

Thank you for providing the tests @dattran-vn01 and for this contribution.

I've added some comments which are all minor. Can you please adjust the ElasticsearchIO JDoc so that it states that the type support is not available for ES6? Perhaps simply:

<p>Optionally, you can provide {@link ElasticsearchIO.Write.FieldValueExtractFn} using {@code withIndexFn()} or {@code withTypeFn()} to enable per-document routing to the target Elasticsearch
index (all versions) and type (version <6). Support for type routing was removed in Elasticsearch 6 (see https://www.elastic.co/blog/index-type-parent-child-join-now-future-in-elasticsearch).  

I had some issues running the integration tests (not your fault) due to the JDoc still referencing Maven commands, and the docker scripts not being correct. Here is how I ran them using your fork and there are things in there @echauchot and I should clean up:
https://gist.github.com/timrobertson100/d4986d13419ee97fac1af2618d93befd

Once ready, I suggest we ask @echauchot to PTAL.

@@ -21,4 +21,4 @@
#Create an ELK (Elasticsearch Logstash Kibana) container for ES v2.4 and compatible Logstash and Kibana versions,

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 14, 2018

Contributor

Nit: v5.4.3 not v2.4

@@ -21,4 +21,4 @@
#Create an ELK (Elasticsearch Logstash Kibana) container for ES v2.4 and compatible Logstash and Kibana versions,

This comment has been minimized.

@timrobertson100

timrobertson100 Aug 14, 2018

Contributor

Nit: v6.3.2 not v2.4

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Aug 14, 2018

Thank you @timrobertson100 for your great support. I updated the PR. I would like to contribute more. Be honestly, This is first time to contribute to open source community so I need to learn a lot of thing from you guys to work effectively.

I see there are still some IO I can contribute as

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 14, 2018

Thanks for accommodating those suggestions @dattran-vn01

I've always been asked to rebase and squash into a single commit and not merge so you might be asked to adjust the commits, but I suggest leaving that until the very end. There are other ES PRs in flight so there might be another conflict depending on the acceptance order.

Can you PTAL @echauchot ? (This PR also addresses BEAM-4911)

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 14, 2018

@dattran-vn01 our messages crossed there.

Thanks to you - it was a pleasure reviewing your work and it's great you are keen to contribute to Beam. I'd suggest the most important things to work on are the ones you need or would use, and the ones that interest you most. I know a few projects that would use a RestfulAPIIO so that sounds like a good addition though. Please be aware that we also strive to "market" the project so if you have anything to blog then that would be a welcome addition too and can be quite rewarding. .

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 15, 2018

Retest this please

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 20, 2018

Hi @dattran-vn01, thanks for you work ! I'm back from vacation, I can take a look in the next few days

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 21, 2018

@dattran-vn01 as a first oversight on the code, I'm glad to see that ESIO v5 code is compatible with ES6 and that the only thing needed is to re-architecture the tests. I'll start a more in depth review soon

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 22, 2018

@dattran-vn01 @timrobertson100 starting the review

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 22, 2018

@dattran-vn01 regarding your commit history, please do not merge master into your feature branch. Instead rebase your branch onto master to have a clean history. See beam contribution guide: we prefer not having parasite merge commits in the history. The only merge commits allowed are the ones that merge PRs into master.

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Aug 22, 2018

Thank you @echauchot Let me close this PR and create a new one without merging master into my feature branch. I will do it in 4 hours.

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 22, 2018

@dattran-vn01 no need to close, just rebase and we will squash the commits in the end. Please do not close otherwise we lose review history. Fell free to ping me on slack for synchronous communication

@echauchot
Copy link
Contributor

echauchot left a comment

@dattran-vn01 Thanks for your work ! And thanks to contribute to Beam ! I have mainly minor comments except 2:

  • the one on the routing support in ES6
  • You need to re-architecture testSplit in both IT and UT
    And a request:
    please run the ITests and show me the status: please sync with @timrobertson100 on this topic
@@ -125,7 +125,8 @@
*
* <p>Optionally, you can provide {@link ElasticsearchIO.Write.FieldValueExtractFn} using {@code
* withIndexFn()} or {@code withTypeFn()} to enable per-document routing to the target Elasticsearch
* index and type.
* index (all versions) and type (version <6). Support for type routing was removed in Elasticsearch
* 6 (see https://www.elastic.co/blog/index-type-parent-child-join-now-future-in-elasticsearch)

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

Good catch ! That being said, there is not only type routing that will be removed but all the type feature in ES ! It will be removed in 7.0. As we know the IO will break in 7.0 I prefer that you put version == 5 || version == 6 everywhere you put version >= 5 to avoid that the users use the IO on incompatible ES v7. We will then do another PR to support ES v7 on the IO. I just opened this ticket to track the future migration: https://issues.apache.org/jira/browse/BEAM-5192. @timrobertson100 I assigned it to you regarding our conversation of yesterday.

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

@dattran-vn01 In addition I don't see the type routing breaking change in v6.x breaking changes list. Are you sure of that? I only see that in 6.0 new created indexes can only contain one type. Please test type routing support and if it is still supported in 6.x please remove the Jdoc comments and leave the feature enabled

This comment has been minimized.

@dattran-vn01

dattran-vn01 Aug 22, 2018

Author

Let me test it again and confirm. Thanks

This comment has been minimized.

@echauchot

echauchot Aug 29, 2018

Contributor

What is the status of that?

This comment has been minimized.

@echauchot

echauchot Sep 5, 2018

Contributor

@dattran-vn01 What is the status of that?


@SuppressWarnings("EmptyMethod")
public static void checkJarHell(Consumer<String> output) {
System.out.println(

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

yes but printing it is unnecessary. please remove the System.out.println

* functions to parse the document and extract the ID is acceptable.
*/
@Test
public void testWriteWithFullAddressingVolume() throws Exception {

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

there was a comment here is ES5 version of the test: it is still true in ES6. please restore it

@@ -106,6 +110,62 @@ void testSizes() throws Exception {
assertThat("Wrong estimated size", estimatedSize, greaterThan(AVERAGE_DOC_SIZE * numDocs));
}

void testSplit5x6x() throws Exception {

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

You need to re-architecture the tests:

  1. ok to introduce testSplit5x6x in TestCommon because ES5 and ES6 split the same and not ES2
  2. ok to introduce an IT version of this test for the same reason
  3. Change ESTestCommon.testSplit5x6x : it should be exactly the same as previous ES5Test.testSplit modulo the final keywords you were right to add. And UTests in ES5 and ES6 should just call elasticsearchIOTestCommon.testSplit5x6x(); not create the index.
  4. Change ESTestCommon.testITSplit5x6x: it should be exactly the same as previous ES5Test.testSplitVolume module the final keywords you were right to add.
@@ -374,6 +433,8 @@ public String apply(JsonNode input) {
* Tests that documents are dynamically routed to different types and not the type that is given
* in the configuration. Documents should be routed to the a type of type_0 or type_1 using a
* modulo approach of the explicit id.
*
* <p>This test does not work with ES 6 because multiple type support within an index was removed.
*/
void testWriteWithTypeFn() throws Exception {

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

rename testWriteWithTypeFn2x5x

@@ -133,8 +133,7 @@ void testReadWithQuery() throws Exception {
+ " \"query\": {\n"
+ " \"match\" : {\n"
+ " \"scientist\" : {\n"
+ " \"query\" : \"Einstein\",\n"
+ " \"type\" : \"boolean\"\n"
+ " \"query\" : \"Einstein\"\n"

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

Nice! I see through the gree UTests that the test still work in ES5 and works in ES6. Thanks

@@ -27,7 +27,7 @@ dependencies {
shadow project(path: ":beam-sdks-java-core", configuration: "shadow")
shadow library.java.jackson_databind
shadow library.java.jackson_annotations
shadow "org.elasticsearch.client:elasticsearch-rest-client:5.6.3"
shadow "org.elasticsearch.client:elasticsearch-rest-client:6.3.2"

This comment has been minimized.

@echauchot

echauchot Aug 22, 2018

Contributor

Nice to see that REST client v 6.3.2 is still retro-compatible with ES2 and ES5. I chose this low level client over the other high level client in the first place to have the common set of production libraries between all the versions. Only test dependencies differ

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Aug 27, 2018

Assuming it is a trivial change can I suggest we jump to 6.4.0 before committing?

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Aug 27, 2018

@timrobertson100 +1 of course
PS: auto deps mecanism will finally stop spamming me :)

@echauchot
Copy link
Contributor

echauchot left a comment

Thanks for the updates !
Only 3 things left:

@@ -93,24 +86,7 @@ public static void afterClass() throws Exception {

@Test
public void testSplitsVolume() throws Exception {

This comment has been minimized.

@echauchot

echauchot Aug 29, 2018

Contributor

There is no more point having a separate testSplitVolume. Only one testSplit method is enough. The only difference between the 2 methods is desiredBundleSizeBytes = 10000. You can add this line to an else in if (!useAsITests) in testSplit.

This comment has been minimized.

@dattran-vn01

dattran-vn01 Sep 1, 2018

Author

Thank you @echauchot I was so busy last week. Today I will have time to fix all.

This comment has been minimized.

@dattran-vn01

dattran-vn01 Sep 2, 2018

Author

Thank @echauchot and @timrobertson100 for great support. But I see I did something wrong (I did not understand git rebase fully) when I tried to resolve conflict and changed testSplitVolume so right now, there are so many commits in this PR. Should I close this PR and open another one?. I'm sorry about that.

This comment has been minimized.

@dattran-vn01

dattran-vn01 Sep 2, 2018

Author

Hi @echauchot , @timrobertson100 I just opened new PR #6326. I only copied what I did and change elasticsearch-tests-2 to use common testSplit

This comment has been minimized.

@dattran-vn01

This comment has been minimized.

@echauchot

echauchot Sep 3, 2018

Contributor

Hi @dattran-vn01 to solve your rebase issue:

  1. checkout master branch to local and update it (pull --rebase) to the latest commits
  2. create a new local branch from master : checkout -b BEAM-5107-ES6
  3. cherry pick the commits you did on branch BEAM-5107-Support-ES-6.x-for-ElasticsearchIO to the new BEAM-5107-ES6 branch. You can cherry pick using Intellij: select the commits in git log history window of branch BEAM-5107-Support-ES-6.x-for-ElasticsearchIO and right-click cherry pick option. It will commit the cherry picked commits to the current branch (BEAM-5107-ES6). Don't forget to remove the "cherry picked from ..." comment in git comment.
  4. force push your branch BEAM-5107-ES6 to the remote branch BEAM-5107-Support-ES-6.x-for-ElasticsearchIO to overwrite it.
    => That way we keep review history and we can close your other PR

This comment has been minimized.

@dattran-vn01

dattran-vn01 Sep 3, 2018

Author

Thank you @echauchot . Let me try it.

This comment has been minimized.

@echauchot

echauchot Sep 3, 2018

Contributor

Also when you cherry pick don't forget to solve the conflicts that might be there.

This comment has been minimized.

@dattran-vn01

dattran-vn01 Sep 4, 2018

Author

Thank you @echauchot . I followed what you guided to solve branch problem. I will run Integration tests again for this PR.

@dattran-vn01 dattran-vn01 force-pushed the dattran-vn01:BEAM-5107-Support-ES-6.x-for-ElasticsearchIO branch from e5406b9 to 3b26227 Sep 4, 2018

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 4, 2018

@echauchot
Copy link
Contributor

echauchot left a comment

The code Looks Good To Me thanks!
But you need to update the ITests:

  1. you have run test ES5 on ES2 instance (see docker run command you pasted in the gist)
  2. Please run IT for ES-test-2 module on a ES2 instance

Javadoc:

  • The build fails to produce correct javadoc. See the error in link in the PR with gradle build scan or jenkins log and fix it
  • squash everything in one commit named [BEAM-5107] Add support for ES-6.x to ElasticsearchIO
@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 5, 2018

Thank you @echauchot I think I posted wrong ES5 docker command but you can see the screenshot is good. It shows Elasticsearch version is 5.4.3

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 5, 2018

Hi @echauchot I will fix java doc, squash commit, and check ES6 type routing. ES-test-2 is good so do I need to run again?

@dattran-vn01

This comment has been minimized.

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 5, 2018

Hi @echauchot Could you please help to explain one thing?
I see Elasticsearch 6 does not allow many types for one index so it means we cannot use type routing in ES6. That's why I added a comment

type (version &gt; 6). Support for type routing was removed in Elasticsearch 6 (see https://www.elastic.co/blog/index-type-parent-child-join-now-future-in-elasticsearch)

I ran testWriteWithTypeFn (now it's renamed to testWriteWithTypeFn2x5x) for ES 6 and it was failed because this test requires many types.

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 5, 2018

Hi @echauchot I fixed all java doc errors. After you check and confirm everything is ok, I will squash everything in one commit named [BEAM-5107] Add support for ES-6.x to ElasticsearchIO. Thank you.

@echauchot

This comment has been minimized.

Copy link
Contributor

echauchot commented Sep 5, 2018

@dattran-vn01 regarding your question about type routing: elastic website says about deprecation.

We plan to introduce a new breaking change currently targeted for 6.0 to make it so new indices will only allow a single type to be created to help you get better prepared for 7.x. Don't worry though -- the multi-type indices you created in 5.x will continue to work as before in 6.x.

So indexes created using ES5 that contain mutli-types still work with ES6. The problem is that in the test we create ES6-version-indexes and those ones do not support multi-types to prepare users for type deactivation in ES7.
IMHO it is a better communication to say to the users that type routing is not supported in ESIO6 rather than saying it is supported only if you created the index using a previous version of ES.
So we can keep it that way.

@echauchot
Copy link
Contributor

echauchot left a comment

LGTM,
you can squash and rename the commit.
Thanks for your work !
And welcome to the Beam contributors family !

@timrobertson100

This comment has been minimized.

Copy link
Contributor

timrobertson100 commented Sep 5, 2018

Thank you @dattran-vn01 and congratulations. This is a really great addition.

Sorry for my silence, but I have been / am very busy on other things this week and next.

@dattran-vn01 dattran-vn01 force-pushed the dattran-vn01:BEAM-5107-Support-ES-6.x-for-ElasticsearchIO branch from e9f136f to 5da843e Sep 6, 2018

@dattran-vn01

This comment has been minimized.

Copy link
Author

dattran-vn01 commented Sep 6, 2018

Thank you @timrobertson100 @echauchot for all supports :) I squashed the commit.

@echauchot echauchot merged commit d427d89 into apache:master Sep 6, 2018

3 of 4 checks passed

Website ("Run Website PreCommit") FAILURE
Details
Go ("Run Go PreCommit") SUCCESS
Details
Java ("Run Java PreCommit") SUCCESS
Details
Python ("Run Python PreCommit") SUCCESS
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.