[NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema #51919

afharo · 2019-11-29T18:19:33Z

Summary

Allow the use of custom validation functions when defining the HTTP routes for those use cases where the use of @kbn/config-schema is not available (like in the browser).
Fixes #50179

Checklist

Use ~~strikethroughs~~ to remove checklist items you don't feel are applicable to this PR.

~~[ ] This was checked for cross-browser compatibility, including a check against IE11~~
~~[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support~~
~~[ ] Documentation was added for features that require explanation or tutorials~~
Unit or functional tests were updated or added to match the most common scenarios
~~[ ] This was checked for keyboard-only and screenreader accessibility~~

For maintainers

This was checked for breaking API changes and was labeled appropriately
This includes a feature addition or change that requires a release note and was labeled appropriately

…chema

elasticmachine · 2019-11-29T18:19:35Z

Pinging @elastic/kibana-platform (Team:Platform)

elasticmachine · 2019-11-29T19:32:12Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request
Commit: 318f827

pgayvallet

To answer the main question, I think this is a valid approach and follows what we discussed at EAH.

I have to admit, I'm a little concerned about the growing types complexity in http route types, even if I don't have suggestion on how to reduce this.

pgayvallet · 2019-12-02T06:56:12Z

src/core/server/http/router/router.ts

+  P extends ObjectType | ValidateFunction<unknown>,
+  Q extends ObjectType | ValidateFunction<unknown>,
+  B extends ObjectType | Type<Buffer> | Type<Stream> | ValidateFunction<unknown>,


Question: (I know this is from a previous PR but,) why do we want to allow user to 'manually' handles body as raw buffer or stream again?

It's a valid question. In the body options:

When parse: false, the body is returned as a Buffer

When output: 'stream', the body is returned as a Stream

So in the config-schema validation, the user needs to specify a valid type validation:

If they do schema.object({}, {allowUnknown: true}), it will not pass validation.

If they don't provide any validation, the body won't be passed through to them

pgayvallet · 2019-12-02T06:58:59Z

src/core/server/http/router/validator.ts

+export type TypeOfFunctionReturn<T extends ValidateFunction<unknown>> = NonNullable<
+  ReturnType<T>['value']
+>;
+
+export type ValidateSpecs<T> = ObjectType | Type<T> | ValidateFunction<T>;
+export type ValidatedType<T extends ValidateSpecs<unknown>> = T extends Type<unknown>
+  ? TypeOf<T>
+  : T extends ValidateFunction<unknown>
+  ? TypeOfFunctionReturn<T>
+  : never;


This is some serious typescript we got there!

Yeah... annoying as hell... To me, lines 49 and 51 should not exist, but TS is not that smart yet and in the right side of the conditional, it doesn't understand the exclusion of T not being Type<unknown> anymore :/

pgayvallet · 2019-12-02T07:04:10Z

src/core/server/http/router/router.ts

 function routeSchemasFromRouteConfig<
-  P extends ObjectType,
-  Q extends ObjectType,
-  B extends ObjectType | Type<Buffer> | Type<Stream>
+  P extends ObjectType | ValidateFunction<unknown>,
+  Q extends ObjectType | ValidateFunction<unknown>,
+  B extends ObjectType | Type<Buffer> | Type<Stream> | ValidateFunction<unknown>


I think you forgot to change this a few lines after?

kibana/src/core/server/http/router/router.ts

Lines 156 to 164 in 066613e

if (route.validate !== false) {

Object.entries(route.validate).forEach(([key, schema]) => {

if (!(schema instanceof Type)) {

throw new Error(

`Expected a valid schema declared with '@kbn/config-schema' package at key: [${key}].`

);

}

});

}

Oh! I thought I did! Maybe it got lost when "fixing" the conflicts... Thank you for spotting it!

pgayvallet · 2019-12-02T07:06:37Z

src/core/server/http/router/router.ts

+    Q extends ObjectType | ValidateFunction<unknown>,
+    B extends ObjectType | Type<Buffer> | Type<Stream> | ValidateFunction<unknown>


given the number of usages in our code, I think type aliases for

ObjectType | ValidateFunction<unknown>

ObjectType | Type<Buffer> | Type<Stream> | ValidateFunction<unknown>

should be a good idea. Will also avoid heavy diffs in further validation type updates.

pgayvallet · 2019-12-02T07:10:58Z

src/core/server/index.ts

+  ValidateFunctionReturn,
+  ValidateFunction,


We usually prefix exports from a given core submodule to avoid collision, I think we want to do this here? RouteXXX probably? Also I think RouteValidationFunction maybe is a better name than RouteValidateFunction?

pgayvallet · 2019-12-02T07:22:04Z

src/core/server/http/router/validator.ts

+ * Custom validate function (only if @kbn/config-schema is not a valid option in your plugin)
+ * @public
+ */
+export type ValidateFunction<T> = (data: any) => ValidateFunctionReturn<T>;


I wonder if we can be a little more restrictive than any here? I think it's a pain as

kibana/src/core/server/http/router/request.ts

Lines 114 to 127 in 066613e

const params =

routeSchemas.params === undefined

? {}

: routeSchemas.params.validate(req.params, {}, 'request params');

const query =

routeSchemas.query === undefined

? {}

: routeSchemas.query.validate(req.query, {}, 'request query');

const body =

routeSchemas.body === undefined

? {}

: routeSchemas.body.validate(req.payload, {}, 'request body');

req.params, req.query, req.payload have different types, but if possible I think at least something like data: reqParamsType | reqQueryType | reqBodyType is a little better (or is it just worse?)

Mega bonus point if we can context-type it depending on if its a query, params or body validation method, but not sure if possible.

I guess the best we can assume here is req.params and req.query to always be Record<string, string>. req.payload is a bit harder to assume any type before validating it (although we've assumed {} up until now and it looks like it didn't harm, especially after Hapi's parsing). I'll see if it can be done without overcomplicating (even more) the typings

afharo · 2019-12-02T09:52:23Z

@elasticmachine merge upstream

elasticmachine · 2019-12-02T11:09:04Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request
Commit: 1b3088a

mshustov · 2019-12-02T10:46:19Z

src/core/server/http/router/validator.ts

+    }
+  | {
+      value?: undefined;
+      error: SchemaTypeError;


This task requires to decouple request validation from @kbm/config-schema. Here it still depends on the package. If '@kbn/config-schema' makes changes in the SchemaTypeError, all routes will have to adopt their validation. We should use an internal error type instead, that '@kbn/config-schema' should satisfy.

Makes sense! I'll export a new type of Error

mshustov · 2019-12-02T11:08:35Z

src/core/server/http/router/validator.ts

+  if (typeof validationSpec === 'function') {
+    return validateFunction(validationSpec, data, namespace);
+  } else {
+    return validationSpec.validate(data, {}, namespace);


so any object with validate method is also allowed?

You are right, TS does a validation but we should add run-time validation.

mshustov · 2019-12-02T11:37:41Z

src/core/server/http/router/router.ts

-  P extends ObjectType,
-  Q extends ObjectType,
-  B extends ObjectType | Type<Buffer> | Type<Stream>,
+  P extends ObjectType | ValidateFunction<unknown>,


would be good to add at least one usage example. in integration tests, e.g.

interface Foo { foo?: number; } test('invalid params', async () => { const router = new Router('/foo', logger, enhanceWithContext); const validate = { params: (params: Foo) => { // TODO add an example with an error const value = typeof params.foo === 'number' ? params.foo || 0; return { value }; }, }; const handler: RequestHandler<typeof validate.params> = (context, req, res) => { console.log(req.body); return res.ok({ body: String(req.params.test) }); }; router.get( { path: '/path-1', validate, }, handler ); const validateKbnSchema = { params: schema.object({ test: schema.string(), }), }; const handlerKbnSchema: RequestHandler<typeof validateKbnSchema.params> = (context, req, res) => { console.log(req.body); return res.ok({ body: String(req.params.test) }); }; router.get( { path: '/path-1', validateKbnSchema, }, handlerKbnSchema );

do you mean this? https://github.com/elastic/kibana/pull/51919/files#diff-51730cbab06a430a940f78fc9e710bd7R290

ah... I overlooked it and wrote my test instead. stupid me 🤣

mshustov · 2019-12-02T11:41:57Z

src/core/server/http/router/router.ts

-  Q extends ObjectType,
-  B extends ObjectType | Type<Buffer> | Type<Stream>,
+  P extends ObjectType | ValidateFunction<unknown>,
+  Q extends ObjectType | ValidateFunction<unknown>,


shouldn't we fallback to = ValidateFunction<unknown> to make all types optional? it would simplify manual declaration:

const handler: RequestHandler<typeof validate.params> = (context, req, res) => { ... };

mshustov · 2019-12-02T11:45:56Z

src/core/server/http/router/validator.ts

+  try {
+    result = validationSpec(data);
+  } catch (err) {
+    result = { error: new SchemaTypeError(err, []) };


I don't follow what a desirable way to fail validation is: to throw an exception or return an exception?

The desirable way is to return { value: validatedValue } or { error: RouteValidationError }. But since we don't have control over the validation method and it can throw an error, we don't want to break the process and throw a 500 error (or do we?).

elasticmachine · 2019-12-02T12:58:09Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: 472a60f

afharo

Thanks for the comments. I'll fix the run-time validation and the fallback in the RequestHandler in a bit and will wait for your thoughts regarding the rest of the discussions.

elasticmachine · 2019-12-02T16:22:16Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request
Commit: b2e06db

afharo · 2019-12-02T17:02:35Z

@elasticmachine merge upstream

elasticmachine · 2019-12-02T17:40:03Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: f5af513

elasticmachine · 2019-12-02T18:18:08Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: 8d02bbe

joshdover · 2019-12-16T19:22:57Z

ack: will review today

joshdover

This design is looking great! Let us know if you need us to take over wrapping this up since you moved teams 😄

Some additional testing I'd like to see:

Validation tests added to src/core/server/http/integration_tests/router.test.ts that verifies the 400 response code and error message.
Functional tests added to test/plugin_functional/test_suites/core_plugins/server_plugins.ts that verifies validation behavior for both config-schema validation and custom validator functions.

joshdover · 2019-12-16T21:59:11Z

src/core/server/http/router/validator/validator.ts

+ *
+ * @public
+ */
+export type RouteValidateFunction<T> = (data: any) => RouteValidateFunctionReturn<T>;


It'd be nice if this function was supplied a factory method for creating RouteValidatorError instances so plugins don't have to import that class manually. I think that'd make this a bit more ergonomic and consistent with the response factories provided to route handlers.

Yeah! Makes perfect sense! That even gave me the idea of providing a RouteValidationResolver that provides the ok and fail methods so the returned contract is maintained. An example of usage: https://github.com/afharo/kibana/blob/np-decouple-configSchema/docs/development/core/server/kibana-plugin-server.routevalidationfunction.md

joshdover · 2019-12-16T22:01:23Z

src/core/server/http/router/validator/validator.ts

+export type RouteValidateFunctionReturn<T> =
+  | {
+      value: T;
+      error?: never;
+    }
+  | {
+      value?: never;
+      error: RouteValidationError;
+    };


I think the intellisense would be improved if this was inlined in the RouteValidateFunction type. It's only referenced in one other place which can be easily replaced with a ReturnType generic.

joshdover · 2019-12-16T22:02:02Z

src/core/server/http/router/validator/validator.ts

+
+/**
+ * Allowed property validation options: either @kbn/config-schema validations or custom validation functions
+ *


Suggested change

*

* See {@link RouteValidateFunction} for custom validation.

joshdover · 2019-12-16T22:03:41Z

src/core/server/http/router/validator/validator.ts

+export type RouteValidationSpec<T> = ObjectType | Type<T> | RouteValidateFunction<T>;
+
+// Ugly as hell but we need this conditional typing to have proper type inference
+type RouteValidatedValue<T extends RouteValidationSpec<any> | undefined> = NonNullable<


How about renaming to RouteValidationResultType?

joshdover · 2019-12-16T22:05:13Z

src/core/server/http/router/validator/validator.ts

+/**
+ * Route validator class to define the validation logic for each new route.
+ *
+ * @private


I'm not sure about the behavior differences, but we've been using @internal

My bad! Well spotted!

joshdover · 2019-12-16T22:05:47Z

src/core/server/http/router/validator/validator.ts

+    return new RouteValidator({ params, query, body }, options);
+  }
+
+  constructor(


with the public static from above, maybe this should be private?

joshdover · 2019-12-16T22:06:21Z

src/core/server/http/router/validator/validator.ts

+  }
+
+  private customValidation<T>(
+    validationRule?: RouteValidationSpec<T>,


I think you can make this non-optional and remove the if undefined below

The thing is the validationRule might be not set. Aka: some routes check body but not params (and the other way around), so you get query and params as undefined and the current logic simply returns those 2 properties as {}.

I might prefer not to return anything at all. But our contract is to always return those params, either the validated value or {} if no validation is provided. The current master implementation does it in a very repetitive way:

kibana/src/core/server/http/router/request.ts

Lines 106 to 129 in 2b6ef5c

if (routeSchemas === undefined) {

return {

body: {},

params: {},

query: {},

};

}

const params =

routeSchemas.params === undefined

? {}

: routeSchemas.params.validate(req.params, {}, 'request params');

const query =

routeSchemas.query === undefined

? {}

: routeSchemas.query.validate(req.query, {}, 'request query');

const body =

routeSchemas.body === undefined

? {}

: routeSchemas.body.validate(req.payload, {}, 'request body');

return { query, params, body };

That makes sense, but I think the defined-ness is already checked in the function that calls this one. It doesn't appear that this method is ever called with an undefined validationRule.

Oh! Eagle eye!

joshdover · 2019-12-16T22:08:02Z

src/core/server/http/router/request.ts

    req: Request,
-    routeSchemas: RouteSchemas<P, Q, B> | undefined
+    routeSchemas: RouteValidator<P, Q, B> | undefined


nit: rename routeSchemas to routeValidator and maybe make optional with ? instead of | undefined?

It makes a difference, ? allows you not to send the parameter. | undefined enforces you to send the parameter, but it accepts the parameter to be undefined. This way you don't forget to send it by mistake ;)

Nevermind, I found a better approach so we always can send the RouteValidator and we can remove the if undefined in it.

…onfigSchema

joshdover

LGTM after these comments, thanks for the expanded test coverage!

joshdover · 2019-12-18T21:11:57Z

src/core/server/http/router/validator/validator.ts

+  validationResolver: RouteValidationResolver,
+  data: any


I would expect these arguments to be in the reverse order to more closely match route handlers (where the input argument (request) comes before the response toolkit).

I did it in that order to somehow enforce the user gets the param :)
But, in order to maintain our convention, I can switch them 👍

joshdover · 2019-12-18T21:12:16Z

src/core/server/http/router/validator/validator.ts

+/**
+ * The custom validation function if @kbn/config-schema is not a valid solution for your specific plugin requirements.
+ *
+ * The validation should look something like:


nit: add the @example tag above this line.

joshdover · 2019-12-18T21:13:58Z

src/core/server/http/router/validator/validator.ts

+ *
+ * @public
+ */
+export interface RouteValidationResolver {


nit: can we call this RouteValidationResultFactory to closer match the KibanaResponseFactory name?

I've also changed the interface so it returns the methods ok and badRequest (instead of fail) to be an even closer match to the response factory :)

…nterface to look more like the KibanaResponseFactory

elasticmachine · 2019-12-19T12:14:57Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: c8c7939

History

💚 Build #16514 succeeded 7d6ea02
💔 Build #16495 failed 1ece254
💔 Build #16474 failed e394259
💔 Build #16431 failed ce57c16
💔 Build #16405 failed be46a67

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

afharo · 2019-12-19T12:16:17Z

@joshdover thank you for your comments. I applied some final changes. If you could give it a final look for a sanity check, I'd appreciate it

…chema (elastic#51919) * [NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema * API docs * Allow validate function in the route handler (run-code validation) * Prefix RouteXXX + Params and Body Validation Aliases * Fix test broken by lodash * Update API docs * Add default types for simpler manual declaration * Add run-time validation of the RouteValidateSpec * Expose RouteValidationError instead of SchemaTypeError * RouteValidator as a class to match config-schema interface * Test for not-inline handler (need to check IRouter for elastic#47047) * Add preValidation of the input for a safer custom validation * Better types for RouteHandlers * [NP] Move route validation to RouteValidator wrapper * Use the class only internally but maintain the same API * Fix types * Ensure RouteValidator instance in KibanaRequest.from * Fix validator.tests (Buffer.from instead of new Buffer) * Default precheck should allow null values * Also allow undefined in preChecks * MR feedback fixes * Provide RouteValidationResolver to the validation function * Add functional tests * Fix new functional tests * Fix validator additional test * Fix test with new resolver * Remove unused import * Rename ValidationResolver to ValidationResultFactory and change the interface to look more like the KibanaResponseFactory Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…chema (#51919) (#53714) * [NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema * API docs * Allow validate function in the route handler (run-code validation) * Prefix RouteXXX + Params and Body Validation Aliases * Fix test broken by lodash * Update API docs * Add default types for simpler manual declaration * Add run-time validation of the RouteValidateSpec * Expose RouteValidationError instead of SchemaTypeError * RouteValidator as a class to match config-schema interface * Test for not-inline handler (need to check IRouter for #47047) * Add preValidation of the input for a safer custom validation * Better types for RouteHandlers * [NP] Move route validation to RouteValidator wrapper * Use the class only internally but maintain the same API * Fix types * Ensure RouteValidator instance in KibanaRequest.from * Fix validator.tests (Buffer.from instead of new Buffer) * Default precheck should allow null values * Also allow undefined in preChecks * MR feedback fixes * Provide RouteValidationResolver to the validation function * Add functional tests * Fix new functional tests * Fix validator additional test * Fix test with new resolver * Remove unused import * Rename ValidationResolver to ValidationResultFactory and change the interface to look more like the KibanaResponseFactory Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…chema (elastic#51919) * [NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema * API docs * Allow validate function in the route handler (run-code validation) * Prefix RouteXXX + Params and Body Validation Aliases * Fix test broken by lodash * Update API docs * Add default types for simpler manual declaration * Add run-time validation of the RouteValidateSpec * Expose RouteValidationError instead of SchemaTypeError * RouteValidator as a class to match config-schema interface * Test for not-inline handler (need to check IRouter for elastic#47047) * Add preValidation of the input for a safer custom validation * Better types for RouteHandlers * [NP] Move route validation to RouteValidator wrapper * Use the class only internally but maintain the same API * Fix types * Ensure RouteValidator instance in KibanaRequest.from * Fix validator.tests (Buffer.from instead of new Buffer) * Default precheck should allow null values * Also allow undefined in preChecks * MR feedback fixes * Provide RouteValidationResolver to the validation function * Add functional tests * Fix new functional tests * Fix validator additional test * Fix test with new resolver * Remove unused import * Rename ValidationResolver to ValidationResultFactory and change the interface to look more like the KibanaResponseFactory Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

afharo added 2 commits November 29, 2019 18:01

[NP] Allow custom validations in HTTP Routes apart from @kbn/config-s…

93cc5db

…chema

API docs

318f827

afharo added release_note:enhancement Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform v8.0.0 v7.7.0 labels Nov 29, 2019

afharo requested a review from a team as a code owner November 29, 2019 18:19

pgayvallet reviewed Dec 2, 2019

View reviewed changes

elasticmachine and others added 3 commits December 2, 2019 01:52

Merge branch 'master' into np-decouple-configSchema

1b3088a

Allow validate function in the route handler (run-code validation)

f9ea319

Prefix RouteXXX + Params and Body Validation Aliases

d28e0aa

afharo added 2 commits December 2, 2019 11:20

Fix test broken by lodash

4fddfd1

Update API docs

472a60f

mshustov reviewed Dec 2, 2019

View reviewed changes

afharo commented Dec 2, 2019

View reviewed changes

afharo added 2 commits December 2, 2019 15:36

Add default types for simpler manual declaration

b2e06db

Add run-time validation of the RouteValidateSpec

3996c2a

Expose RouteValidationError instead of SchemaTypeError

f5af513

Merge branch 'master' into np-decouple-configSchema

8d02bbe

joshdover reviewed Dec 16, 2019

View reviewed changes

afharo added 10 commits December 17, 2019 16:23

Merge branch 'master' of github.com:elastic/kibana into np-decouple-c…

6a6b0ab

…onfigSchema

Merge branch 'master' of github.com:elastic/kibana into np-decouple-c…

c10723a

…onfigSchema

MR feedback fixes

5c45228

Provide RouteValidationResolver to the validation function

fb0e6ad

Add functional tests

be46a67

Fix new functional tests

ce57c16

Merge branch 'master' of github.com:elastic/kibana into np-decouple-c…

3b930f3

…onfigSchema

Fix validator additional test

e394259

Fix test with new resolver

1ece254

Remove unused import

7d6ea02

joshdover approved these changes Dec 18, 2019

View reviewed changes

Rename ValidationResolver to ValidationResultFactory and change the i…

c8c7939

…nterface to look more like the KibanaResponseFactory

joshdover approved these changes Dec 20, 2019

View reviewed changes

afharo merged commit 3bdbcd0 into elastic:master Dec 20, 2019

afharo deleted the np-decouple-configSchema branch December 20, 2019 17:53

afharo mentioned this pull request Dec 20, 2019

[7.x] [NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema (#51919) #53714

Merged

kobelb mentioned this pull request Jan 7, 2020

hapi request payload hardening #49609

Open

pgayvallet mentioned this pull request Jan 8, 2020

Router should accept arrays or primitives a body payloads #54268

Closed

joshdover mentioned this pull request Feb 25, 2020

Use more permissive validation in request mock #58557

Merged

7 tasks

joshdover added v7.6.0 and removed v7.7.0 labels Apr 14, 2020

	if (route.validate !== false) {
	Object.entries(route.validate).forEach(([key, schema]) => {
	if (!(schema instanceof Type)) {
	throw new Error(
	`Expected a valid schema declared with '@kbn/config-schema' package at key: [${key}].`
	);
	}
	});
	}

		Q extends ObjectType \| ValidateFunction<unknown>,
		B extends ObjectType \| Type<Buffer> \| Type<Stream> \| ValidateFunction<unknown>

	const params =
	routeSchemas.params === undefined
	? {}
	: routeSchemas.params.validate(req.params, {}, 'request params');

	const query =
	routeSchemas.query === undefined
	? {}
	: routeSchemas.query.validate(req.query, {}, 'request query');

	const body =
	routeSchemas.body === undefined
	? {}
	: routeSchemas.body.validate(req.payload, {}, 'request body');

	if (routeSchemas === undefined) {
	return {
	body: {},
	params: {},
	query: {},
	};
	}

	const params =
	routeSchemas.params === undefined
	? {}
	: routeSchemas.params.validate(req.params, {}, 'request params');

	const query =
	routeSchemas.query === undefined
	? {}
	: routeSchemas.query.validate(req.query, {}, 'request query');

	const body =
	routeSchemas.body === undefined
	? {}
	: routeSchemas.body.validate(req.payload, {}, 'request body');

	return { query, params, body };

[NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema #51919

[NP] Allow custom validations in HTTP Routes apart from @kbn/config-schema #51919

Conversation

afharo commented Nov 29, 2019 • edited Loading

Summary

Checklist

For maintainers

elasticmachine commented Nov 29, 2019

elasticmachine commented Nov 29, 2019

💔 Build Failed

pgayvallet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afharo Dec 2, 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afharo commented Dec 2, 2019

elasticmachine commented Dec 2, 2019

💔 Build Failed

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

elasticmachine commented Dec 2, 2019

💚 Build Succeeded

afharo left a comment

Choose a reason for hiding this comment

elasticmachine commented Dec 2, 2019

💔 Build Failed

afharo commented Dec 2, 2019

elasticmachine commented Dec 2, 2019

💚 Build Succeeded

elasticmachine commented Dec 2, 2019

💚 Build Succeeded

joshdover commented Dec 16, 2019

joshdover 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

joshdover 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

elasticmachine commented Dec 19, 2019

💚 Build Succeeded

History

afharo commented Dec 19, 2019

afharo commented Nov 29, 2019 •

edited

Loading

afharo Dec 2, 2019 •

edited

Loading