While working on some tests, I was having a tricky problem in a test suite. Eventually I tracked it down to an interaction between tests. I suspected the test library, but once I tried to make an isolated test case, I realized the test library was working fine. It turns out it was the server’s request cache. The fix is to clear the cache between tests.
Not needed for this PR, though I’m adding it to this branch because it conflicts with this change.
Running the server in process is necessary for the mock to work. This is an approach I’ve taken in the past. I experimented with this setup quite a bit when I was playing around with a test suite, and it seemed to work well enough. Setting `process.argv` is a admitedly a bit gross, though a cleaner approach would require more involved changes to `server.js`.
Given the chunks coming from imagemagick are getting stored memory and
then tucked into a cache, this function could as easily return a buffer
via callback. Streaming is just making it more complex. (And trickier to
test!)
In ef1a5159, the switch to using imagemagick made a faulty use of the library by
listening for an 'end' event that is never raised. As a result, the cache was
never populated.
In d985f81f, a fix that takes care of the fact that the previously mentioned
dead code relies on a non-existent variable caused it to kill the server when a
raster badge is requested twice, as what it stored in the cache was the pipe
transmitting chunks, not the chunks themselves, and the pipe (a Socket object)
cannot be subsequently sent through a pipe. The following error occured instead:
events.js:163
throw er; // Unhandled 'error' event
^
TypeError: Invalid non-string/buffer chunk
at chunkInvalid (_stream_readable.js:395:10)
at readableAddChunk (_stream_readable.js:150:12)
at DataStream.Readable.push (_stream_readable.js:136:10)
at DataStream._read (/home/m/shields/lib/svg-to-img.js:45:21)
at DataStream.Readable.read (_stream_readable.js:350:10)
at resume_ (_stream_readable.js:739:12)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickDomainCallback (internal/process/next_tick.js:128:9)
The OpenAPI Specification (formerly known as the Swagger RESTful API
Documentation Specification) defines a format for describing RESTful
APIs. The Swagger project provides a set of tools for working with this
format, including a hosted validator which provides a validation badge
and JSON result.[1] This commit adds shields.io support for this badge.
The service currently only provides validation of files conforming to
version 2.0 of the OpenAPI Specification. This commit adds a path
component for specifying the version under the assumption that the
validator may support version 3.0 or later as they are released.
It accepts the URL to validate as two path components, a scheme followed
by the rest of the URL, to match the convention used for the JIRA host
and webpage online shields.
Changes in v2:
- Use bitbucket in try.html example for clarity.
- Change /v/ in URL to /valid/ to avoid conflict with v=version.
1. https://github.com/swagger-api/validator-badge
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The following warning is emitted by Node.js:
> DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new
> Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or
> `Buffer.alloc()` instead.
This patch removes this warning.
Projects that have '0' technical debt would otherwise receive a
lightgrey badge instead of a brightgreen one.
Signed-off-by: Sebastian Hoß <mail@shoss.de>
The old LRU implementation stored a list's indices to reference items in that
list, but deletions from the list made indices point to the wrong slot.
Functionally, it meant that deleted slots were not guaranteed to be the oldest
slot.
Using a linked list fixes that.
Prior to this patch, time spend in badge.js (computing text width and
compressing the SVG with SVGO) averaged 8.4 ms.
After this patch, it clocks at 2.4 ms on average.
Assuming this is the CPU bottleneck, it means that servers used to only be able
to handle 119 req/s (empirically, it is closer to 100 req/s). It should now
handle 416 req/s (although a better guess is at 1/0.004 = 250 req/s).
