[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges; also affects [apm appveyor cdnjs clojars gem] #1743

paulmelnikow · 2018-06-19T17:15:24Z

When JSON responses come back, they are sometimes not in the format expected by the API. As a result we have a lot of defensive coding (expressions like (data || {}).someProperty) to avoid exceptions being thrown in badge processing. Often we rely on the try blocks that wrap so much of the badge-processing code, which catch all JavaScript exceptions and return some error result, usually invalid. The problem with this is that these try blocks catch all sorts of programmer errors too, so when we see invalid we don't know whether the API returned something unexpected, or we've made a mistake. We also spend a lot of time writing defensive tests around malformed responses, and creating and maintaining the defensive coding.

A better solution is to validate the API responses using declarative contracts. Here the programmer says exactly what they expect from the API. That way, if the response isn't what we expect we can just say it's an invalid json response. And if our code then throws an exception, well that's our mistake; when we catch that we can call it a shields internal error. It's also less code and less error-prone. Over time we may be confident enough in the contracts that we won't need so many tests of malformed responses. The contract doesn't need to describe the entire response, only the part that's needed. Unknown keys can simply be dropped, preventing unvalidated parts of the response from creeping into the code. Checking what's in our response before calling values on it also makes our code more secure.

I used Joi here, since we're already using it for testing. There may be another contracts library that's a better fit, though I think we could look at that later.

Those changes are in base.js.

The rest is a rewrite of the remaining NPM badges, including the extraction of an NpmBase class. Inspired by @chris48s's work in #1740, this class splits the service concerns into fetching and plucking, validation, and rendering. There are two URL patterns, one which allows specifying a tag (used by e.g. the version badge https://img.shields.io/npm/v/npm/next.svg), and the other which does not accept a tag (e.g. the license badge https://img.shields.io/npm/l/express.svg). Subclasses like NpmLicense and NpmTypeDefinitions can specify the URL fragment, examples, the validation schema for the chunk of the package data they use, and a render function. The NpmVersion subclass uses a different endpoint, so it overrides the handle implementation from NpmBase.

Rewriting these was curiously difficult. There were a few factors, I think: a large paradigm shift, lots of code duplication to sift through, red herring abstractions (abstractions that already exist but are actually unhelpful in the new paradigm), and new problems to solve (namely validation). I leaned heavily on the thorough tests. Thank goodness for those!

Sort of aside: seeing a service like NPM with a lot of services inside it, I wonder if we should change the file layout of our services a bit. It would be nice not to have to write npm/npm.js which just loads up all the other test classes. Maybe instead of e.g. appveyor/appveyor.js we should call it appveyor/appveyor.service.js, and when a service has more than one file with service classes, they could be called npm/npm-license.service.js, npm/npm-version.service.js, etc. Also I often wanted to run just the license tests, or just the version tests. Shorter test files – maybe separate npm/npm-version.tester.js – would make that easier to manage.

Todo before merging:

shields-ci · 2018-06-19T17:18:40Z

	Warnings
⚠️	This PR modified service code for apm but not its test code. That's okay so long as it's refactoring existing code.
⚠️	This PR modified service code for appveyor but not its test code. That's okay so long as it's refactoring existing code.
⚠️	This PR modified service code for cdnjs but not its test code. That's okay so long as it's refactoring existing code.
⚠️	This PR modified service code for clojars but not its test code. That's okay so long as it's refactoring existing code.
⚠️	This PR modified service code for gem but not its test code. That's okay so long as it's refactoring existing code.

	Messages
📖	✨ Thanks for your contribution to Shields, @paulmelnikow!
📖	Thanks for contributing to our documentation. We ❤️ our documentarians!

Generated by 🚫 dangerJS

chris48s · 2018-06-20T21:21:01Z

I've not attempted to do a full review as its still WIP, but here's a few comments based on your original post and a read-through of the code:

I think the fetch, validate, render pattern here is good in most cases. In some cases where we're doing a lot of processing, it might also be useful for us to think about the steps as fetch, validate, transform, render.

If the schema stops validating because the upstream API has changed (or because we've made a poor choice of regex and need to tweak it), does this make the error any less visible, or more difficult to debug? Do you think its worth thinking about logging or sending something to sentry when a response fails to validate? That seems like something we want to be aware of in most cases.

Is this kind of validation going to be flexible enough to deal with situations where we have to accept multiple different patterns (I'm thinking of stuff like this and this ). Its really annoying, but it happens and we need to deal with it..

Do you think there's any danger that adding the concept of design by contact here introduces additional friction for new contributors? As you rightly point out in #1272 one of the strengths of this project is the wide potential contributor base. I think I'm probably on the side that this is OK because funamentally we're not asking anyone to learn anything they don't need to know in order to write tests. Maybe the perspective of another maintainer would be useful here. (slight side issue: One of the things I've started to think about is updating the tutorial to reference the new structure as I think at the moment we're adding new badges to server.js faster than we're refactoring but I'm also conscious that we're evolving the structure as we go and we need to have the API nailed down a bit more first). Its worth thinking about how to document this in an accessible way, anyway.

seeing a service like NPM with a lot of services inside it, I wonder if we should change the file layout of our services a bit

The most common case is where we support one badge, or a sufficiently small number that defining them in one file isn't an issue, but it would be nice if we could also easily split large services across multiple files and split the test suites up more easily. It may also be necessary to change the danger.js rule I've defined. It might be a bit naive and need tweaking to account for the changes?

You've probably already considered these, but I'll mention them for completeness:

Since you're refactoring npm code, [npm] should be in the PR title.
In order to merge this, you'll need to update the other service code which extend BaseJsonService, otherwise all the badges we've already refactored will throw Error: Subclasses should define a response schema. For reference, the other services that will need to be updated are:
- Appveyor
- Cdnjs
- Clojars
- Ruby Gems

chris48s · 2018-06-20T21:30:32Z

services/base.js

  async _requestJson(url, options = {}, notFoundMessage) {
    return this._sendAndCacheRequest(url,
      {...{ 'headers': { 'Accept': 'application/json' } }, ...options}
    ).then(
      checkErrorResponse.asPromise(
        notFoundMessage ? { notFoundMessage: notFoundMessage } : undefined
      )
-    ).then(asJson);
+    ).then(asJson
+    ).then(json => this.constructor.validateResponse(json));


Is there any tradeoff in calling this.constructor.staticMethod() vs ClassName.staticMethod(), or is it just a stylistic consideration?

Yea, it allows subclasses to redefine the class method being invoked, and have the expected thing happen.

# Conflicts: # package.json

paulmelnikow · 2018-07-19T04:10:02Z

I think the fetch, validate, render pattern here is good in most cases. In some cases where we're doing a lot of processing, it might also be useful for us to think about the steps as fetch, validate, transform, render.

Yes, agreed!

If the schema stops validating because the upstream API has changed (or because we've made a poor choice of regex and need to tweak it), does this make the error any less visible, or more difficult to debug? Do you think its worth thinking about logging or sending something to sentry when a response fails to validate? That seems like something we want to be aware of in most cases.

That seems reasonable. While I suspect some failures will be transient, probably others will be permanent. Given strict schema validation could cause some new failures, Sentry has tools to basically snooze errors. seems like erring on the side of logging is fine. I wonder if there’s a way we can pipe the useful context, like the end user’s request parameters, to Sentry.

Do you think there's any danger that adding the concept of design by contact here introduces additional friction for new contributors? As you rightly point out in #1272 one of the strengths of this project is the wide potential contributor base. I think I'm probably on the side that this is OK because funamentally we're not asking anyone to learn anything they don't need to know in order to write tests. Maybe the perspective of another maintainer would be useful here. (slight side issue: One of the things I've started to think about is updating the tutorial to reference the new structure as I think at the moment we're adding new badges to server.js faster than we're refactoring but I'm also conscious that we're evolving the structure as we go and we need to have the API nailed down a bit more first). Its worth thinking about how to document this in an accessible way, anyway.

Yea, agreed with all of this. I’m concerned about introducing additional friction, too. I like the argument you make: that we’re not asking people to learn anything they don’t already need to learn in order to write tests. Another reason I think it’s justified is that there isn't a more accessible alternative. Trying to write validation code from scratch may seem easier, but it's harder to get right, and the code reviews would frustrate most contributors. We’re committed to providing useful error messages, and one of the things we need to do is distinguish programmer errors from response errors. In other words, it’s a necessary hurdle, basically endemic to the problem Shields is solving.

Would appreciate other perspectives. Definitely think it’s a good idea to start a tutorial for the new-style services. Since they’re not yet feature-complete I’m unsure whether to recommend new contributors try to write them. Maybe we could start by adding a new section in the readme.

chris48s · 2018-07-19T22:15:23Z

Definitely think it’s a good idea to start a tutorial for the new-style services. Since they’re not yet feature-complete I’m unsure whether to recommend new contributors try to write them.

At the moment I think we're still at the stage where each time one the core team does a chunk of refactoring we end up evolving the structure a little bit as we hit more edge cases. I'd like to be at a stage where we've refactored a couple more services without needing to tinker with the base classes first. I think it will also be useful to have a decent number of examples people can use as a base to crib code from. We're close though..

paulmelnikow · 2018-07-20T03:17:54Z

Would anyone else like to weigh in about the requirement to write Joi contracts for JSON responses? @platan @PyvesB @RedSparr0w

And please stop rewriting this file! https://medium.com/@martin_hotell/stop-re-formatting-package-json-with-prettier-and-vscode-once-and-for-all-52d283067f9a

paulmelnikow · 2018-07-20T05:01:42Z

services/npm/npm-base.js

+      const registryTag = tag || 'latest';
+      const latestVersion = json['dist-tags'][registryTag];
+      packageData = json.versions[latestVersion];
+    }


I'm thinking about this could be restructured to use fetch, validate, transform, render. I'm realizing also that there's a problem with the way this is written now. When the response comes back invalid, it's possible to crash above during plucking, before we hit the validateResponse call.

I'm thinking about how to restructure this.

It seems right that handle should invoke fetch and render.

Either of these seem okay: that handle invoke validateResponse, or that it's handled by fetch.

It seems good for handle be be responsible to invoke transform, and not so good for that to be handled by fetch.

It would be good to avoid writing boilerplate in handle. However the more things happen magically, the more difficult services are to read. This is the basic argument for "code over configuration": everything is more direct.

🤔

After mulling this over a while, and playing with a couple different versions, I'm leaning toward this approach:

Require validation and handle it in _requestJson().

Rather than make fetch–transform–render into a framework, make it a design pattern. That gives us the benefits of a clear structure, including testability, with less magic.

Invoke render() with a props object that is already cleaned and transformed. Do the transform work directly in handle() or delegate to a static transform() method if there's a testability benefit.

Add render() to BaseService for generate static examples without api call [apm appveyor cdnjs clojars gem npm uptimerobot] #1740.

A few things I'd like to improve:

Since NpmBase has a method for creating the URL pattern, also give it a method for unpacking the URL too. This should reduce errors when the signature changes.

As discussed, send invalidated responses to Sentry.

Easier debugging, especially of the contracts, by adding some kind of logging and debugging instrumentation.

Curious to see how this version reads!

PyvesB · 2018-07-22T20:23:10Z

I find that having contracts for API responses is a good idea.

Nevertheless, should we try to "hide" all Joi-based checks in a separate class, a bit like we do with our test validators?

this will help reusability and prevent code duplication.
this will allow us to more easily swap out Joi for another library, rather than having to revisit each single service file (related to @paulmelnikow comment "There may be another contracts library that's a better fit, though I think we could look at that later.").
this will help out out new contributors and hopefully minimise friction. They will be able to use easily understandable functions (isPositiveInteger, isLicenseList, etc.) without having to necessarily dig into the Joi documentation. If they do have to implement a new validator for an API, it will be much easier for them to have all our existing contracts in one place rather than having to run around the code base to get inspiration.

Those are my thoughts on this matter. 😉

paulmelnikow · 2018-07-27T21:12:26Z

Nevertheless, should we try to "hide" all Joi-based checks in a separate class, a bit like we do with our test validators?

Yea, this makes sense, and is pretty much what this is trying to do. Service implementers have to write the contracts, but the framework will run them.

this will help out out new contributors and hopefully minimise friction. They will be able to use easily understandable functions (isPositiveInteger, isLicenseList, etc.) without having to necessarily dig into the Joi documentation. If they do have to implement a new validator for an API, it will be much easier for them to have all our existing contracts in one place rather than having to run around the code base to get inspiration.

Most of the shared Joi contracts we have now are "leaf nodes" – a string that could be this value or that value, a positive integer, as you say, etc. I'm cool with continuing to use those for leaf nodes that get repeated. It saves typing and improves readability. Many of these are also for shared aspects of the Shields interface (i.e. the output of our metric() or file size functions).

For higher level contracts – structural things like arrays of certain length, choice of two options, and possibly even relationships between objects within the structure, if we re-wrap all of the functionality we need, that's a lot of interface to design and documentation to write.

If the problem is that we don't like the Joi documentation or primitives, maybe it would be better to shop around for another library. Or, we could use shared contracts for "leaf nodes" in common. I don't think it's practical to abstract away Joi without creating a lot of extra work for ourselves.

Another option would be to write a tutorial for writing simple contracts with Joi. That could ease the learning curve for contract newbies, and make for a nicer transition into the Joi API docs.

# Conflicts: # lib/all-badge-examples.js

# Conflicts: # lib/all-badge-examples.js # server.js

These are now covered by the test on the base service.

chris48s

Sorry it has taken a while to give this another read-though. Its quite a big refactor so it requires carving out a bit of time to look over it properly. I've left a few more comments but this is heading in a great direction.

chris48s · 2018-08-04T15:28:36Z

services/npm/npm.js

+  NpmVersion,
+  NpmLicense,
+  NpmTypeDefinitions,
+].concat(NpmDownloads);


I think this can now be removed in favour of renaming the files as per #1797.
Similarly /node/node.js wants to be /node/node.service.js.

chris48s · 2018-08-04T15:31:03Z

services/base.js

+    }
+  }
+
+  async _requestJson({ schema, url, options = {}, notFoundMessage }) {


Do you think it is worth explicitly checking schema has been passed here? If we pass undefined to Joi.validate(), it will throw AssertionError [ERR_ASSERTION]: Invalid schema content: but I wonder if it is worth throwing a 'friendlier' error in that case? I can see that being a common pitfall for new contributors. Would another way to 'enforce' this be for schema to be a class property instead of a function param. e.g:

static schema() { throw new Error('must define schema'); }

Also, it seems like there will be a certain amount of cases where we do actually want to pass Joi.any() (it looks like that is what you are doing for NpmLicense and NpmTypeDefinitions in this PR). We definitely don't want that to be the default case but is it worth providing some kind of 'shorthand' for that case?

So, yea, I had the schema in as a class property before (static get responseSchema) but ended up making it a parameter. The schema compilation step is slow, so we don't want to compile a new schema every time we have a new request. Since we don't have class properties yet, that means we need to memoize it somehow, or else define it outside the class. Passing it in the call to _requestJson seems like less typing, is just as clear, and is possible to use conditionally.

Joi.any() seems like a good shorthand to me. Were you thinking something like shouldValidate: false? I'd be okay with that. However I don't want contributors to think that validating is optional. 😉 Maybe not having a shortcut is okay.

I'm good with adding a check with a better error message. Probably we should check that it's a Joi schema. I think Joi supports compiling from object literals, though constructing them all literally is self-documenting.

The schema compilation step is slow, so we don't want to compile a new schema every time we have a new request.

We've got enough performance problems at the moment. Lets not make that any worse ;)

Maybe not having a shortcut is okay.

OK. Lets ignore that for now. Once we've refactored some more stuff we'll have an idea of how common this case is going to be.

I'm good with adding a check with a better error message. Probably we should check that it's a Joi schema.

Yeah, lets ensure that schema exists and is an instance of Joi and throw an error which provides a hint if not.

chris48s · 2018-08-04T15:31:23Z

services/base.js

@@ -23,6 +25,12 @@ class BaseService {
    this._handleInternalErrors = handleInternalErrors;
  }

+  static render(props, namedParams, queryParams) {


Can you give an example of when we need to pass namedParams, queryParams to render()? I don't think they get used anywhere in this PR.

Number formatting, or work like in #1321 is an example. Would it be better to pass that stuff through props?

I can see how if we went with the 'framework' approach, it would be useful to make these available here, but given we have to manually implement render(), construct all the stuff we want to pass it and call it ourselves, I think we should probably just explicitly pass what we need into props.

chris48s · 2018-08-04T15:33:51Z

Rather than make fetch–transform–render into a framework, make it a design pattern. That gives us the benefits of a clear structure, including testability, with less magic.

I think this is a good way to look at it. One of the things I've found helpful as part of the review is to also look also look at what happens if we refactor a very simple service. I think this latest refactor strikes a good balance between giving us the structure to handle complex cases like this but without over-complicating very simple cases. Also it means if we are just doing something non-standard it is easier to deal with.

For higher level contracts – structural things like arrays of certain length, choice of two options, and possibly even relationships between objects within the structure, if we re-wrap all of the functionality we need, that's a lot of interface to design and documentation to write.

I think its fine for this to 'evolve' in the same way service test validators have. I wouldn't be in favour of building a complete wrapper or inner platform over Joi, but if we find we are looking for the same patterns across multiple badges or services, we can extract that pattern and wrap it. I think it is inevitable that there will be certain checks that do fit this pattern so probably worth thinking about where those should live.

paulmelnikow · 2018-08-04T19:03:24Z

Thanks for sharing that link!

paulmelnikow · 2018-08-04T19:07:14Z

Should we drop empty contracts into the remaining services and address those in follow-on PRs?

chris48s · 2018-08-04T21:52:45Z

Should we drop empty contracts into the remaining services and address those in follow-on PRs?

Yep - lets not increase the scope of this PR too much. If we do the minimum required to get the other new-style services (APM, Appveyor, Cdnjs, Clojars, Ruby Gems) working with the new base class structure here then we can look at improving those as another job.

paulmelnikow · 2018-08-05T00:47:26Z

Sounds great. I'll address two remaining comments (schema instanceof Joi; pass only props to render), shim the new-style services, and aim to get this in quickly.

paulmelnikow · 2018-08-07T04:03:19Z

Addressed remaining items. Should be good for a last review! @chris48s

paulmelnikow · 2018-08-08T19:23:38Z

Hey @chris48s, would you like me to wait until you have a chance to review again, or shall I go ahead and merge this?

chris48s

I've had a quick look over the latest commits and I reckon this is good to go 👍 . Lets get this merged. As next steps, I will have a look at fleshing out the validation on the other services, revisit #1740 and continue to refactor some more services in this style.

paulmelnikow · 2018-08-08T21:03:48Z

Great. Thanks for reviewing!

I’ll tackle some service refactoring too. Let’s coordinate in #1358 so we don’t duplicate work!

shields-deployment · 2018-08-08T21:08:20Z

This pull request was merged to master branch. Now this change is waiting for deployment.
Deploys usually happen every few weeks. After deployment changes are copied to gh-pages branch.

This badge displays deployment status:

Rewrite NPM badges

9e40a35

paulmelnikow added the core Server, BaseService, GitHub auth, Shared helpers label Jun 19, 2018

Update package-lock

1f58cd1

paulmelnikow mentioned this pull request Jun 19, 2018

generate static examples without api call [apm appveyor cdnjs clojars gem npm uptimerobot] #1740

Merged

Fix npm tagged version

06a8dbf

chris48s reviewed Jun 20, 2018

View reviewed changes

paulmelnikow changed the title ~~[RFC] Add Joi-based request validation to BaseJsonService and rewrite NPM badges~~ [RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] badges Jul 19, 2018

Merge branch 'master' into rewrite-npm

a41acb8

# Conflicts: # package.json

chris48s mentioned this pull request Jul 19, 2018

throw if given invalid version, refactor [apm] #1785

Merged

3 tasks

paulmelnikow mentioned this pull request Jul 20, 2018

Turn on prettier (except repo root) #1167

Merged

3 tasks

Merge branch 'master' into rewrite-npm

9b8c476

paulmelnikow added 5 commits July 19, 2018 20:23

Null edit to package.json to try to fix build

6d1378b

Revert

b53a940

package.json: Reset to master to fix build

3d35290

And please stop rewriting this file! https://medium.com/@martin_hotell/stop-re-formatting-package-json-with-prettier-and-vscode-once-and-for-all-52d283067f9a

More cleanup

88d3889

license -> back to miscellaneous

a09631e

paulmelnikow commented Jul 20, 2018

View reviewed changes

paulmelnikow mentioned this pull request Jul 20, 2018

Fix edge case for service detection in PR titles [cran] [crates] #1790

Merged

paulmelnikow added 2 commits July 20, 2018 17:00

WIP

0d0dbfc

Merge branch 'master' into rewrite-npm

1afae73

paulmelnikow added 4 commits July 22, 2018 19:37

Finish up another pass

df5b2f4

Merge branch 'rewrite-npm-take-2' into rewrite-npm

0d2a224

Clean diff

c50153c

Clean a bunch of diff

e90a2e7

paulmelnikow added 5 commits July 27, 2018 16:14

Merge branch 'master' into rewrite-npm

4b10f76

# Conflicts: # lib/all-badge-examples.js

Merge branch 'master' into rewrite-npm

7500796

# Conflicts: # lib/all-badge-examples.js # server.js

misc -> license

c643402

Fix failing test

4e2ae6b

Remove npm tests whose behavior has changed

ac7d993

These are now covered by the test on the base service.

chris48s reviewed Aug 4, 2018

View reviewed changes

paulmelnikow added 2 commits August 4, 2018 14:47

Merge branch 'master' into rewrite-npm

3c8ea5a

Rename based on new naming convention

38d81fb

One missed rename

0d94e3d

paulmelnikow added 2 commits August 6, 2018 23:42

Throw a friendly error when schema is not provided

d831943

Rm extra params from render() signature

16dc017

paulmelnikow changed the title ~~[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges~~ [RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges [apm appveyor cdnjs clojars gem] Aug 7, 2018

Shim existing services

ce51076

chris48s approved these changes Aug 8, 2018

View reviewed changes

paulmelnikow merged commit e3b1005 into badges:master Aug 8, 2018

paulmelnikow deleted the rewrite-npm branch August 8, 2018 21:08

chris48s mentioned this pull request Aug 9, 2018

The Great Service Rewrite 🏆 #1358

Closed

PyvesB mentioned this pull request Aug 9, 2018

Customise AppVeyor Test 'passed', 'failed', 'skipped' status #1321

Closed

chris48s mentioned this pull request Aug 10, 2018

Validate response json in [apm appveyor cdnjs clojars gem] also affects [npm] #1883

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges; also affects [apm appveyor cdnjs clojars gem] #1743

[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges; also affects [apm appveyor cdnjs clojars gem] #1743

paulmelnikow commented Jun 19, 2018 •

edited

Loading

shields-ci commented Jun 19, 2018 •

edited

Loading

chris48s commented Jun 20, 2018

chris48s Jun 20, 2018

paulmelnikow Jun 25, 2018

paulmelnikow commented Jul 19, 2018

chris48s commented Jul 19, 2018

paulmelnikow commented Jul 20, 2018

paulmelnikow Jul 20, 2018

paulmelnikow Jul 23, 2018 •

edited

Loading

PyvesB commented Jul 22, 2018 •

edited

Loading

paulmelnikow commented Jul 27, 2018

chris48s left a comment

chris48s Aug 4, 2018

chris48s Aug 4, 2018

paulmelnikow Aug 4, 2018

chris48s Aug 4, 2018

chris48s Aug 4, 2018

paulmelnikow Aug 4, 2018

chris48s Aug 4, 2018

chris48s commented Aug 4, 2018

paulmelnikow commented Aug 4, 2018

paulmelnikow commented Aug 4, 2018

chris48s commented Aug 4, 2018

paulmelnikow commented Aug 5, 2018

paulmelnikow commented Aug 7, 2018

paulmelnikow commented Aug 8, 2018

chris48s left a comment

paulmelnikow commented Aug 8, 2018

shields-deployment bot commented Aug 8, 2018

[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges; also affects [apm appveyor cdnjs clojars gem] #1743

[RFC] Add Joi-based request validation to BaseJsonService and rewrite [NPM] and [node] badges; also affects [apm appveyor cdnjs clojars gem] #1743

Conversation

paulmelnikow commented Jun 19, 2018 • edited Loading

shields-ci commented Jun 19, 2018 • edited Loading

chris48s commented Jun 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulmelnikow commented Jul 19, 2018

chris48s commented Jul 19, 2018

paulmelnikow commented Jul 20, 2018

Choose a reason for hiding this comment

paulmelnikow Jul 23, 2018 • edited Loading

Choose a reason for hiding this comment

PyvesB commented Jul 22, 2018 • edited Loading

paulmelnikow commented Jul 27, 2018

chris48s 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

chris48s commented Aug 4, 2018

paulmelnikow commented Aug 4, 2018

paulmelnikow commented Aug 4, 2018

chris48s commented Aug 4, 2018

paulmelnikow commented Aug 5, 2018

paulmelnikow commented Aug 7, 2018

paulmelnikow commented Aug 8, 2018

chris48s left a comment

Choose a reason for hiding this comment

paulmelnikow commented Aug 8, 2018

shields-deployment bot commented Aug 8, 2018

paulmelnikow commented Jun 19, 2018 •

edited

Loading

shields-ci commented Jun 19, 2018 •

edited

Loading

paulmelnikow Jul 23, 2018 •

edited

Loading

PyvesB commented Jul 22, 2018 •

edited

Loading