v0.9.2

I remember v0.9.1, it felt like it was less than a week ago.

It was, but we have another new version of Hoverfly already! This new version contains a few usability fixes as well as a fix to a bug.

Locked in memory cache bug

This week, we discovered a bug. This bug was only noticeable when running Hoverfly with the in memory database. The problem was, if you made a request to the cache and it failed, the cache would remain locked, making it impossible to ever read or write from the cache without resetting Hoverfly. This has been fixed up now and the in memory cache should not get stuck in a locked state any more.

Pretty JSON

When exporting data to a JSON file with hoverctl, the file it would write would always have the simulation JSON on one line, making it hard to read. Now, hoverctl will write JSON in a more formatted way, making it easier to read your simulations.

For more information on exporting simulations Exporting captured data

Invalid simulation parsing

With v0.9.0, we introduced a new schema for the simulation. This schema is slightly more complicated than the previous. One of the issues we found was that when creating your own simulation files, Hoverfly gave no validation on this schema. Now, when importing a simulation file, if it doesn't match the expected schema, it will now report the error.

For more information on simulations Managing simulation data

hoverctl start reports ports

Another small piece of feedback we had was that it wasn't always clear which ports Hoverfly had started on when using the hoverctl tool. We've updated hoverctl to now log the admin and proxy ports when starting an instance of Hoverfly.

For more information on hoverctl Hoverctl reference

v0.9.1

What better way to celebrate Cyber Monday with the Cyber Monday Hoverfly Deal! Download Hoverfly, and get hoverctl, absolutely free!

Its been two weeks since the release of Hoverfly v0.9.0 and we are ready for the next release. This version features many smaller changes to hoverctl to make it easier to use.

hoverctl destination

We've introduced the destination command to hoverctl. This will return the destination being used by the running Hoverfly instance. Much like the other hoverctl commands, you can also use this to set the destination. Also, Hoverfly will now match the destination against full URLs, both destination and path.

hoverctl destination '<regex>'

For more information on setting the destination Filtering destination

hoverctl support for custom certificate and key files

Previously, if you wanted to use a certificate and key which were different than the defaults, you would have to launch Hoverfly manually. With this version, we've introduced the --certificate and --key flags to hoverctl.

hoverctl start --certificate /path/to/certificate.pem --key /path/to/key.pem

For more information on new flags Hoverctl flags

hoverctl can disable TLS

Much like the certificate and key values, if you wanted to disable TLS verification on Hoverfly, this could only be done by providing a flag to the Hoverfly binary. Hoverctl now supports this functionality when starting an instance of Hoverfly.

hoverctl start --disable-tls

For more information on new flags Hoverctl flags

New config for hoverctl config.yaml

All of these new flags introduced in this version of hoverctl have been included in the config.yaml. By default, hoverctl will always check the config.yaml and use any configuration to start Hoverfly. If for example, you always disable TLS verification, instead of providing the flag each time, you could just edit the config file to include hoverfly.tls.disable: true.

For more information on new flags Hoverctl configuration

New config command

If you are unsure of the configuration that hoverctl is using, we've added a new command to find out. Calling the config command in hoverctl will now report the location of the config.yaml that it is using as well as printing the configuration that is being used.

hoverctl config

For more information on new command Hoverctl config

v0.9.0

Its been a while but we are back! Hello! There have been some big changes to Hoverfly. A lot of the past month has been spent implementing the groundwork needed for us to continue to develop and evolve Hoverfly with more confidence of backwards compatibility.

With this release, we are deprecating the old API. We believe the new V2 API covers all of the required functionality. The old API is still accessible, but it will be removed at some point in the future.

With this release out of the way, we plan to go back to smaller, more regular releases in the future.

Revised schema

Over time, the input files required for Hoverfly have grown. Initially, there was a records file containing requests and responses. We then introduced templates and then delays. v0.9.0 simplifies all of this and now has a new schema for simulations. This schema contains all everything Hoverfly needs. The simulation schema now has the recorded requests and respones, the templates and the delays. In the future, any new forms of data we support in Hoverfly will be delivered via this schema.

For more information on the new schema: Managing simulation data

V2 API

We've been hard at work on building out a new RESTful API for Hoverfly. This new API is versioned, which should allow us to make changes more easily without breaking backwards compatibility. As part of the new API, we've created a new endpoint for getting simulations with the new schema.

For more information on the new API: API reference

v0.8.2

Happy National Ampersand Day! What better way to celebrate today by showing your appreciation for the ampersand & checking out the latest release of Hoverfly. Its a small release today with a new feature and a bug fix. But before that, I would like to warn you about upcoming changes.

Recently we've been adding features and expanding the functionality of Hoverfly. This has been fantastic but as a result, we've slowly made it more complicated to use with different sets of data required with their own import and export steps. We've been starting to work on v0.9.0 which plans to change this and simplify both request templates and delays. To make these changes, we're are going to be making breaking changes and creating a new version of the API, v2. I'm keeping a wiki page for breaking changes so that we can clearly communicate these breaking changes ahead of time

For more information on these breaking changes: Upcoming breaking changes

Wildcards in request templates

The introduction of request templates was a great feature. It allowed for more flexible simulations. We have now expanded upon this to allow you to make your new simulations even more flexible. Instead of specifying a complete string to match against, its now possible to include an asterisk to substitute characters, similar to using a UNIX command line. This can be used in any of the fields available in a request template.

For more information on wildcards in request templates: Managing simulation data

Saving redirects

A bug was found when trying to create a simulation of an OAuth2 log in. When the log in occurred, we spotted that the redirects were not being stored. Further investigation found that Hoverfly was executing the redirects and then returning a response as if the redirect never happened. This bug has been fixed, and now Hoverfly will return a redirect without executing it.

v0.8.1

Greetings one and all. It’s Friday and Monday is a public holiday in the UK. The weather is looking good and Hoverfly is looking better. Here is v0.8.1 and the changes it introduces.

“RequestResponsePairs” and “RequestTemplateResponsePairs”

For this release we have focused on refactoring, specifically around how Hoverfly simulation data is managed. In the past, we have referred to this data with different names - this hasn't always been clear.

From v0.8.1 we have defined a new standard for naming. Gone are the days of generic “payloads”. Requests and responses are now formed together to become RequestResponsePairs. We plan on updating the documentation to make sure that we always refer to simulation data now as pairs.

Along with this change, we have been refactoring data importing and exporting. Previously, if you wanted to make use of request templates or delays, you would have to create new files. We feel that this is unnecessary and that all data pertaining to a simulation should live in one file. This release allows request templates to be added to your normal simulation recordings.

For more information on request response pairs: Managing simulation data

Headers in webserver mode

A bug was discovered in webserver mode in which headers would not be included in the response. We have patched this up and written tests around it.

For more information on webserver mode: Server type

Matching on body with request templates

Another bug was discovered while using request templates. Despite being an option, you could not match on the request template body. This has been fixed in this version, again with tests around it.

For more information on request templates: Matching requests

v0.8.0

It's that time where we make a Hoverfly release! It's my favourite time as I get to review all the exciting work we've put into Hoverfly.

Partial matching with request templates

Before v0.8.0, matching within Hoverfly on requests was very strict and a bit brittle. You couldn't match a request just on the destination and a header - such as the Authorization header. Before, you had to capture every request that you wanted to match against using the same destination and header. v.0.8.0 changes that. We've introduced the ability to match on certain key elements of the request. You want to match on any POST request? Now you can. You want to match any request for the favicon regardless of destination? Now you can.

This is a powerful feature that can help make simulations more flexible. We are very excited about this feature and has helped us already.

For more information on request templates: Matching requests

Changing middleware via hoverctl

In our continuous effort to move towards making hoverctl the wrapper for managing Hoverfly processes, we introduced the ability to set middleware via hoverctl. This now means that is no longer necessary to start Hoverfly with middleware. Using the hoverctl, you can now set it during run time, making it easier than ever to swap out middleware as and when you need it.

For more information on setting middleware via hoverctl: Hoverctl

Remote execution of middleware

As part of the middleware change, we've been curious as to how you could set middleware on remote machines running Hoverfly, especially without needing SSH access to the box. Our solution was to introduce the ability to run middleware as a web service. Instead of providing Hoverfly a command and a file to execute, you can now provide a URL instead. Building remote middleware is incredibly easily and using serverless technology like AWS Lambda makes working with middleware even easier.

For more information on remote execution of middleware: Using middleware

v0.7.1

Its been less than a week but its time for another release! Since the last release, we've been listening to feedback and implemented some changes to make Hoverfly just that little bit better than it already was.

URL and HTTP Method Matching on Response Delays

In v0.7.0 we introduced response delays, a great way to introduce delays into your simulations. With v0.7.1, we've expanded the functionality of response delays. Originally, you could only apply delays based on host. We've expanded it. You can now apply delays based on the full URL path and HTTP methods. This change allows for your response delays to be much more flexible.

This change means that the "hostPattern" field in your response delays will now need to be "urlPattern". Response delays will no longer work with "hostPattern"

For more information on response delays: Simulating service latency

Logging in Hoverctl

Another big feature of v0.7.0 was the introduction of hoverctl, the command line tool for interacting with both Hoverfly and your simulation data inside it. One of the biggest drawbacks to using hoverctl was that if you started an instance of Hoverfly using it, you lost access to the logs. This is no longer the case. We've added logs to hoverctl. You can how call hoverctl logs and get access to the Hoverfly logs. Need to tail the logs and follow them in real time? Not a problem, use the --follow flag.

For more information on hoverctl: hoverctl reference

--version

Both Hoverfly and hoverctl did not have --version flags, making them noncompliant with POSIX guidelines. v0.7.1 adds the --version flag to both Hoverfly and hoverctl.

For more information on hoverctl: hoverctl reference

For more information on Hoverfly flags: Hoverfly flags and environment variables

Hoverfly on Homebrew

Its been a requested feature for a while. Hoverfly is now available using Homebrew. This formula includes both Hoverfly and hoverctl. It is currently not available on homebrew-core and instead, resides in its own SpectoLabs tap.

If you want to install Hoverfly via Homebrew, please run brew install SpectoLabs/tap/hoverfly

v0.7.0

Greetings!

We've been busy adding new features to Hoverfly, as well as developing tools to support the use of Hoverfly.

Hoverctl

We have created a new command line interface for Hoverfly. This allows for the management of local and remote Hoverfly instances. Using hoverctl, you can start and stop instances of Hoverfly, and manage Hoverfly data. You can export your simulations and then share them on SpectoLab, an API simulation repository for sharing and retrieving simulations. SpectoLab is currently in private beta, but you can request access. Hoverctl will still work with Hoverfly, even if you don't have access to SpectoLab.

For more information on hoverctl: hoverctl reference

Install script

Run the following command to install and set up Hoverfly and hoverctl:

curl -o install.sh https://storage.googleapis.com/specto-binaries/install.sh && bash install.sh

Add response delays (without using middleware)

We noticed that a common usage of middleware was to introduce response delays to simulations, so we've added the ability to set response delays in Hoverfly without the need for middleware. Hoverfly uses a regex to match against a request, opening up the opportunity to add different delays to different hosts.

For more information on response delays: Simulating service latency

Run Hoverfly as a webserver

We also got feedback that running Hoverfly as a proxy was not always desirable (or even possible), especially when simulations have been recorded previously and all you need is simulate mode. Now Hoverfly can run as a webserver, allowing you to point your application directly at Hoverfly without having to configure a proxy. Currently this only works via HTTP.

For more information on running Hoverfly as a webserver: Server type

Other stuff

Also, this release introduces a new repository structure. This was mainly due to the introduction of hoverctl. The end result is a much tidier repository that makes it easy to run different suites of functional tests.

v0.6.0

Its time for a new minor version of Hoverfly.

Why have we gone from v0.5.17 to v0.6.0?

We made a slight change to the structure of payloads. We added a new field to indicate whether or not the body needs to be base64-encoded. The reason being that during the export and import process, any binary body data in a response would get lost due to being parsed to Unicode characters.

You can find out more about this change here. If you are trying to read or write binary data to the response body in your middleware, find out more here.

In this release, we have also introduced Ginkgo and Gomega to help us functionally test Hoverfly, which in turn has enabled us to start to modularize the codebase.

v0.5.17

Next version of UI and improved documentation