Releases: SpectoLabs/hoverfly
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
v0.5.16
v0.5.15
- BoltDB backend moved to separate package, currently used for requests/responses and metadata storage.
- Request body is now being minified before creating unique fingerprint ID to remove all spaces/new line symbols for JSON and XML content types.
- Destination can now be updated through API (restarts proxy goroutine)