Remove Circle CI stuff so it doesn’t get confusing for devops. Also add configuration documentation to aid in production deploys and setup.

Author: jmgasper

.circleci/circle.yml

@@ -25,28 +25,7 @@ npm run lint
 
 ## Configuration
 
-The following config parameters are supported, they are defined in `config/default.js` and can be configured in system environment:
-
-
-| Name                           | Description                                | Default                          |
-| :----------------------------- | :----------------------------------------: | :------------------------------: |
-| PORT                           | the port the application will listen on    |  3000                            |
-| LOG_LEVEL                      | the log level                              |  info                            |
-| TOPIC                          | the kafka subscribe topic name             |  tc-x-events                    |
-| KAFKA_OPTIONS                   | the connection option for kafka            |  see below about KAFKA options                   |
-| MONGODB_URL  | the MongoDB URL which must be same as Topcoder x tool | mongodb://127.0.0.1:27017/topcoderx|
-
-KAFKA_OPTIONS should be object as described in https://github.com/SOHU-Co/kafka-node#kafkaclient
-For using with SSL, the options should be as
-```
- {
-    kafkaHost: '<server>',
-    sslOptions: {
-      cert: '<certificate>', 
-      key:  '<key>'
-    }
- }
-```
+See "configuration.md"
 
 `config/local.js` will not tracked by git.
 
@@ -63,8 +42,6 @@ use `ngrok` to make your local deploy accessible by internet:
 ngrok http 3002
 ```
 
-Copy the forwarding URL to set in `HOOK_BASE_URL` of topcoder-x in config.json
-
 ## Setup for verification
 Before verifying the tool, 3 service needs be configured and run them
 - processor
@@ -101,4 +78,4 @@ Now, receiver service can receive the webhooks from git host's project. Now you
 - add/remove a label to an issue, you can see the logs in `receiver` and `processor`, the `issue.labelUpdated` event is generated.
 - create a pull request, you can see the logs in `receiver` and `processor`, the `pull_request.created` event is generated.
 - close a pull request without merge, you can see the logs in `receiver` and `processor`, the `pull_request.closed` event is generated and the `merged` property is `false`.
-- merge a pull request, you can see the logs in `receiver` and `processor`, the `pull_request.closed` event is generated and the `merged` property is `true`.
+- merge a pull request, you can see the logs in `receiver` and `processor`, the `pull_request.closed` event is generated and the `merged` property is `true`.

README.md

@@ -0,0 +1,59 @@
+# Topcoder x receiver configuration
+The following config parameters are supported, they are defined in `config/default.js` and can be configured in env variables:
+
+
+| Name                                   | Description                                | Default                          |
+| :------------------------------------- | :----------------------------------------: | :------------------------------: |
+| PORT                                   | The port the application will listen on    |  3002                            |
+| LOG_LEVEL                              | The log level                              |  info                            |
+| MONGODB_URI                            | The MongoDB URI.  This needs to be the same MongoDB used by topcoder-x-receiver, topcoder-x-processor, and topcoder-x-site                           | mongodb://127.0.0.1:27017/topcoderx |
+|TOPIC  | The Kafka topic where events are published.  This must be the same as the configured value for topcoder-x-processor| |
+|KAFKA_OPTIONS | Kafka connection options| |
+|KAFKA_HOST | The Kafka host to connect to| localhost:9092 |
+|KAFKA_CLIENT_CERT | The Kafka SSL certificate to use when connecting| Read from kafka_client.cer file, but this can be set as a string like it is on Heroku |
+|KAFKA_CLIENT_CERT_KEY | The Kafka SSL certificate key to use when connecting| Read from kafka_client.key file, but this can be set as a string like it is on Heroku|
+
+KAFKA_OPTIONS should be object as described in https://github.com/SOHU-Co/kafka-node#kafkaclient
+For using with SSL, the options should be as
+```
+ {
+    kafkaHost: '<server>',
+    sslOptions: {
+      cert: '<certificate>',
+      key:  '<key>'
+    }
+ }
+```
+
+## Endpoints
+
+- POST /webhooks/github - The webhook handler for github
+- POST /webhooks/gitlab - The webhook handler for gitlab
+
+## Github Verification
+
+#### Webhook configuration
+
+Configure a Github project with a webhook with a format like this: https://<receiver URL>:<receiver port>/webhooks/github
+
+#### Smoke test
+- Create an issue in the repo, you can see the logs in `receiver`, the `issue.created` event is generated.
+
+You can test other events, but just validating that an issue.created event is generated in Kafka is enough to smoke test the receiver is set up properly.  
+
+#### Debugging
+You can re-run and debug the responses to webhook requests on Github, in the configuration for the webhook.  This can be useful if things aren't coming through properly in the receiver.
+
+## Github Verification
+
+#### Webhook configuration
+
+Configure a Gitlab project with a webhook with a format like this: https://<receiver URL>:<receiver port>/webhooks/gitlab
+
+#### Smoke test
+- Create an issue in the repo, you can see the logs in `receiver`, the `issue.created` event is generated.
+
+You can test other events, but just validating that an issue.created event is generated in Kafka is enough to smoke test the receiver is set up properly.  
+
+#### Debugging
+You can re-run and debug the responses to webhook requests on Gitlab, in the configuration for the webhook.  This can be useful if things aren't coming through properly in the receiver.