Releases: ptarmiganlabs/butler
butler-v6.1.0
butler-v6.0.1
Documentation
- Added src readme (0b7465a)
butler-v6.0.0
⚠ BREAKING CHANGES
- Refactor the entire REST API. This includes many endpoints getting new/more appropriate error (and in some cases success) codes. Please see butler.ptarmiganlabs.com for details.
- MQTT message now taken from body rather than from URL params
Features
Bug Fixes
- File copy/move now returns 201 (86d63ca), closes #216
- Key-value store now working as intended (4fb9201), closes #222
- MQTT message now taken from body (a92bdf1), closes #217
- security: Better cert handling, fixes #192 (da933bd)
Miscellaneous
- deps: Update dependencies
- Update base base image for Docker builds (e50154a)
- A few new config file settings related to (dis)allowing unverified TLS certificates.
- A new config setting
backgroundServerPort
used to implement the X-HTTP-Method-Override feature (see below). Can be set to any free port number. Only used within Butler itself (does not need to be accessible from outside).
Refactoring
butler v5.4.3
Some Docker love
This release doesn't add any new features nor does it address any bugs.
It simply switches to using GitHub Actions for building the linux/amd64 Docker images.
A bit simpler to maintain, a bit faster builds. Nice.
Updated dependencies
Staying sharp - updated deps to stay secure and fast.
Bug fix & documentation updates
New features
Fixes and patches
-
Fixed bug occuring when the start-task API was called with an empty PUT body. #157
-
Improved documentation around the Sense data connections that Butler needs. #160, #156.
-
Clarified that Butler requires InfluxDB 1.x. InfluxDB 2.x is great, but bring breaking features wrt Butler. #159.
Changed behavior and/or breaking changes
Key-value store refinements
New features (in no particular order)
- Added REST API endpoint for getting a list of all keys that exist in a given key-value store namespace.
Useful when you need to iterate over all KV pairs in a namespace. #150.
Fixed bugs
- The parsing of the YAML config file is now a bit more robust and tolerant for sections that have a header but no contents. #152.
Reload task parameters, anyone? Yes we can!
This has been a pain point of Qlik Sense even since it was first launched.
Of course it should be possible to send parameters to reload tasks.... except you can't.
At least not from the QMC.
Task parameters can be implemented in different ways, with Butler v5.2 we went for a rather generic solution that can be extended quite far, if needed.
Key-value pairs as parameters
The idea is simple:
When starting a task using Butler's REST API you specify
- The task ID
- An array of key-value pairs. Each KV pair lives in a namespace (used to partition KV pairs as needed) and has an optional time-to-live value, after which it is deleted. You can pass in zero, one, ten or a hundred KV pairs - there's no firm limit set except that each namespace is limited by default to 1000 KV pairs.
- The parameters are stored in Butler's KV store. From there they can be accessed by Butler's regular REST API, just as any other KV pairs.
- When a downstream app during its reload need some data from as previous app (or from the external start-task event), it just pulls the needed KV pair from the KV store and that's it. Task parameters for dummies.
To make things even easier there are helper functions that wrap the actual calls to Butler's REST API.
Starting a reload task from a Sense load script - and pass along parameters - is as easy as
Call StartTask_KeyValue('fbf645f0-0c92-40a4-af9a-6e3eb1d3c35c', 'MyNamespace', 'An important key', 'The value', 3000)
Sharing is caring - let's make future Butler versions great!
It's only been a week since 5.0.0 was released but here is already another release from you friendly Butler team.
It's not the biggest of updates, it's more about setting the stage for things to come.
The one thing that's new is... drum roll...
Telemetry
Wait - is that a good thing??
In this case it is.
We've given this one a lot of thought. Let's give it some context first though.
Historically, the development of Butler has largely been driven by what features were needed at some specific point in time.
That's fine, but it also means that the Butler developers have been in the dark as to
- which Butler features are actually used
- which features no-one uses
- on which operating systems Butler is used etc.
On the other hand: If team Butler would know which features are used most, which OSs Butler is used on etc, they could focus future work towards those high-value features and platforms.
In other words. Adding telemetry is about making future Butler versions better for you.
100% anonymous
This one we won't compromise on.
Only anonymized data leaves your Butler instance(s).
Not even the IP of the computer sending the telemetry data is kept.
We're serious about this one - full discussion and transparency at butler.ptarmiganlabs.com.
Full list of changes available in the changelog.
Documentation available at butler.ptarmiganlabs.com, as always.