Releases: eclipse-hawkbit/hawkbit
0.6.1
🚀 New features
- Add DMF support in hawkbit SDK (#1708)
- Introduce READ_TENANT_CONFIGURATION permission (#1713)
- Add docker configuration for Simple UI (#1719)
- Support for OAuth2 resource server with issuer URI (#1731)
- Add PollStatus to result of list targets via REST API (#1734)
- Add REST method for update rollout (#1749)
- Tests for dynamic rollouts (#1777)
👍🏻 Improvements
- Ignore isEmpty methods in MgmtTargetAttributes and MgmtDistributionSetAssignments in order to avoid invalid schematic (#1794)
- Involve all targets in dynamic rollout (#1795)
- Improve building of SQL from an RSQL query (#1766)
- Prevent deletion of Software Module of locked DS #1793 (#1793)
- Optimize RSQL Visitor G2 (#1828)
- Refactor RSQL search fields related classes (#1834)
⬆️ Version upgrades
- Spring version to 3.3.5 (#1914)
🐞 Bugs fixed
- Handle error when iterating over active rollouts (#1747)
- Fix lastModifiedBy on modification perfomed by the JpaRolloutExecutor (#1748)
❗ Removed features
- Remove download by downloadId functionality (#1820)
0.5.0
🚀 New features
- Add EXPERIMENTAL support for dynamic rollouts (#1533)
- Support for Software Module & Distribution Set lock (#1580)
- Distribution Set implicit lock: Support testing mode (#1651)
- Make Amqp Handler service conditional (#1567)
- Expose externalRef in Rest API (#1655)
- Add roles and hierarchies (#1673)
👍🏻 Improvements
- Fix missing information in rest doc (#1618)
⬆️ Version upgrades
- Spring version to 3.2.2 (#1584)
🐞 Bugs fixed
- Fix rollout and rollout group status in Simple UI (#1636)
❗ Removed features
- Vaadin 8 based UI is removed from hawkBit as announced in Vaadin 8 UI Discontinuation (#1510, see also #1376)
0.4.1
🚀 New features
- Splitting monolith hawkbit application to different microservices (#1490)
- Extend access control management with entity-based access control (#1493)
- Introduce hawkBit Simple UI based on Vaadin 24 (#1499)
- Target Type unified with Software Module & Distribution Set Types (#1509)
👍🏻 Improvements
- Documentation improvements (#1481)
- Vaadin 8 Discontinuation doc announcement (#1486)
- Improved Docker build and Docker Images (#1488)
⬆️ Version upgrades
- Spring version to 2.7.18 (#1519)
🐞 Bugs fixed
- Fix of sending DistributionSetDeletedEvent twice (#1478)
0.3.0
🚀 New features
OpenApi (Swagger) support
This feature enables our Management API and Direct Device Integration API to be available in the newly integrated Swagger
- Introduce swagger support in #1432
- Make the OpenApi configuration conditional in #1437
- Additional example values in #1441
- Add bearer auth for Management API in #1468
Retry of a Rollout
This new feature enables a rollout to be retried only over failed targets after being completed.
- Introduce Retry rollout in #1454
More Features
- Extend System Configuration to support Default Distribution Set Type(#1457)
- OICD Pluggable permission mapper (#1469)
- OpenApi Doc generation (#1442)
- Remove Spring Rest Doc (#1446)
🚀 Features included in milestone releases
User Consent Flow
This new feature facilitates the implementation of user consent requirements (e.g. as mandated by the European Tangible Goods Directive) by enhancing the action state machine with a new state WAITING_FOR_CONFIRMATION. Whenever a new deployment action is initiated (e.g. through a rollout or a manual assignment), it needs to be confirmed first before it enters the state RUNNING. If the confirmation is rejected, the action continues to be in state WAITING_FOR_CONFIRMATION until it is confirmed at a later point in time or cancelled. To accept or reject a pending confirmation, device implementors can use the Direct Device Integration API (DDI) or the Device Management Federation API (DMF). In case of DDI, a new "confirmationBase" resource has been introduced providing the information about pending confirmations and the associated updates. For DMF, a new "CONFIRM" message has been introduced, informing the target device about open confirmations.
In addition, a target device can also be set into an auto-confirm state to indicate that all future actions of this device shall be confirmed automatically. This enables two use cases: Operators might want to disable the confirmation phase for specific test devices, whereas end-users might want to enable automatic updates and give their consent for all future updates (until revoked). The auto-confirm state can either be set by target devices via DDI and DMF, or by operators via Management API and UI.
This feature was contributed by @dimitar-shterev, @strailov, @ramannas, and @herdt-michael in #1293
- Support user consent flow by @herdt-michael in #1293
Target Types
By default, all targets are compatible to all distribution sets. This means, every valid distribution set, that has the required software modules assigned, can be assigned for installation to all available targets. However, some targets might not support the content of the distribution set, but the assignment of it is possible with Eclipse hawkBit, nevertheless. To avoid such wrong assignments and for the sake of user guidance, it is possible to restrict the general compatibility using target types and define for presumably different types of targets the specific types of distribution sets that they are compatible with.
- Feature target type filter by @aktivk in #1197
- Feature target with target type in UI by @aktivk in #1178
- Feature - TargetType compatibility check by @singrob in #1180
- Implement target type CRUD UI operations by @vkandrotas in #1184
- Feature target type entity by @aktivk in #1162
Manually Trigger the Next Rollout Group
This new rollout feature gives you more flexibility in controlling the execution of your rollout groups. Typically, the cascaded execution of rollout groups is controlled by the so-called "trigger threshold". The trigger threshold specifies a percentage of target devices which have finished their installation of the assigned firmware update. When the trigger threshold is exceeded, the next rollout group will be executed.
There are cases, however, when the trigger threshold of a rollout group is never met, for example, if too many target devices are offline. As a consequence, the execution of your rollout, in particular the execution of the remaining rollout groups, might be stuck. To overcome this state, you can now manually trigger the next rollout group, without waiting for the trigger threshold to be reached. The new feature is offered as part of the Management API and Management UI.
- Trigger next rollout group - backend and management API implementation by @dimitar-shterev in #1294
Management API: New Resource Collection /rest/v1/actions
This new Management API feature provides read-only access to the collection of deployment actions via the context path "/rest/v1/actions". Furthermore, it allows you to filter this collection in a very flexible way by defining FIQL queries (request parameter 'q'). For example, you can define the following queries:
- Find all actions that match a certain action status (e.g. downloaded, finished, error, scheduled etc.).
- Find all actions that were spawned by a certain rollout.
- Find all actions that failed with a certain status code.
- Find all actions that refer to a certain distribution set.
So far, the collection of deployment actions could only be accessed for a specific target device ("action history"). With this new API, you can retrieve the data that is relevant for your specific scenario and feed it into your own custom UIs (e.g. dashboards) to monitor and troubleshoot your firmware updates.
- Add resource collection /rest/v1/actions to Management REST API by @stefbehl in #1299
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Add new endpoint for single action by @strailov in #1316
DDI-API: InstalledBase
Installed Base is a new feature which extends the DDI API with the "installedBase" endpoint that behaves similar to "deploymentBase" but instead of providing the latest on-going assignment, it provides the latest installed Distribution Set information. It can be used in multiple scenarios of a factory reset, device sync, etc.
Support for Action Status Codes
This new feature enables targets to optionally include a status code into their action status feedback messages that are sent to Eclipse Hawkbit. The feature is supported via DDI and DMF. Annotating action status entries with status code simplifies the troubleshooting of software updates, e.g. by detecting error clusters matching a specific status code.
- Introduce action status scoped custom code by @herdt-michael in #1277
- Introduce action status scoped custom code - part 2 by @stefbehl in #1281
- Adding last action status code in view Rolloutgroup targets by @blomark in #1295
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Management API: Expose lastStatusCode property of action entities by @stefbehl in #1313
More features 🚀
- Additional tag filtering by targetId and distributionSetId (#1381)
- Filter Distribution sets by assigned Software modules (#1386)
- Add statistics for Distribution set (#1388)
- Extend get Module artifacts API by download url (#1390)
- Batch system configuration update (#1402)
- Extend Rollout filtration fields with status and Distribution set (#1380)
- Optional controller attributes for THING_CREATED by @bogdan-bondar (#1154)
- PostgreSQL support (#932)
- Mgmt API accepts and returns SHA256 file hash (#918)
- OpenID Connect support (#865)
- DDI supports SHA256 (#869)
- CORS support for Mgmt API (#854)
- Support for Multi-Assignments #833
- Add multi-user support #829
- Feature download only #810
👍🏻 Improvements
- Switching license from EPL v1 to v2 (#1427)
- Replace Jetty with Tomcat as web server (#1379)
- Refactoring TargetFilterQueryManagement (#1108)
- Refactor AutoAssignExecutor to improve the extensibility (#1110)
- Set DdiActionFeedback ID deprecated (#1091)
- Align target queries to only use specifications (#1148)
- Introduce new tenant configuration ...
Contributors
Assets 2
0.3.0M9
🚀 New features
- Additional tag filtering by targetId and distributionSetId (#1381)
- Filter Distribution sets by assigned Software modules (#1386)
- Add statistics for Distribution set (#1388)
- Extend get Module artifacts API by download url (#1390)
- Add statistics for Distribution set (#1388)
- Change the structure of Distribution Set Statistics response body (#1397)
- Batch system configuration update (#1402)
- Extend Rollout filtration fields with status and Distribution set (#1380)
👍🏻 Improvements
- Remove retry attempts for AMQP messages which violates a quota (#1392 )
- Replace Jetty with Tomcat as web server (#1379)
⬆️ Version upgrades
🐞 Bugs fixed
- Enforce decoding on authentication check (#1362)
New Contributors
- @avgustinmm made their first contribution in #1371
- @denislavprinov made their first contribution in #1380
- @memoos made their first contribution in #1392
Contributors
Assets 2
0.3.0M8
🚀 New Features
User Consent Flow
This new feature facilitates the implementation of user consent requirements (e.g. as mandated by the European Tangible Goods Directive) by enhancing the action state machine with a new state WAITING_FOR_CONFIRMATION. Whenever a new deployment action is initiated (e.g. through a rollout or a manual assignment), it needs to be confirmed first before it enters the state RUNNING. If the confirmation is rejected, the action continues to be in state WAITING_FOR_CONFIRMATION until it is confirmed at a later point in time or cancelled. To accept or reject a pending confirmation, device implementors can use the Direct Device Integration API (DDI) or the Device Management Federation API (DMF). In case of DDI, a new "confirmationBase" resource has been introduced providing the information about pending confirmations and the associated updates. For DMF, a new "CONFIRM" message has been introduced, informing the target device about open confirmations.
In addition, a target device can also be set into an auto-confirm state to indicate that all future actions of this device shall be confirmed automatically. This enables two use cases: Operators might want to disable the confirmation phase for specific test devices, whereas end-users might want to enable automatic updates and give their consent for all future updates (until revoked). The auto-confirm state can either be set by target devices via DDI and DMF, or by operators via Management API and UI.
This feature was contributed by @dimitar-shterev, @strailov, @ramannas, and @herdt-michael in #1293
- Support user consent flow by @herdt-michael in #1293
Target Types
By default, all targets are compatible to all distribution sets. This means, every valid distribution set, that has the required software modules assigned, can be assigned for installation to all available targets. However, some targets might not support the content of the distribution set, but the assignment of it is possible with Eclipse hawkBit, nevertheless. To avoid such wrong assignments and for the sake of user guidance, it is possible to restrict the general compatibility using target types and define for presumably different types of targets the specific types of distribution sets that they are compatible with.
- Feature target type filter by @aktivk in #1197
- Feature target with target type in UI by @aktivk in #1178
- Feature - TargetType compatibility check by @singrob in #1180
- Implement target type CRUD UI operations by @vkandrotas in #1184
- Feature target type entity by @aktivk in #1162
Invalidation of Distribution Sets
Imagine following scenario: A new software update was distributed to many thousand devices using the auto assignment feature. After a few hundred devices have downloaded the update, a major issue within the software is detected and any further software rollout needs to be stopped immediately. The mass-canceling of running update actions can be achieved by invalidating the distribution set the major issue was detected on. The invalidation can be done either via the Management API or the UI.
- Introduce basic functionality for invalidation of distributionsets by @sebastian-firsching in #1179
- Feature invalidation of distribution sets [UI part] by @blomark in #1176
- Feature mass cancel running actions on ds invalidation by @Nkyn in #1177
Manually Trigger the Next Rollout Group
This new rollout feature gives you more flexibility in controlling the execution of your rollout groups. Typically, the cascaded execution of rollout groups is controlled by the so-called "trigger threshold". The trigger threshold specifies a percentage of target devices which have finished their installation of the assigned firmware update. When the trigger threshold is exceeded, the next rollout group will be executed.
There are cases, however, when the trigger threshold of a rollout group is never met, for example, if too many target devices are offline. As a consequence, the execution of your rollout, in particular the execution of the remaining rollout groups, might be stuck. To overcome this state, you can now manually trigger the next rollout group, without waiting for the trigger threshold to be reached. The new feature is offered as part of the Management API and Management UI.
- Trigger next rollout group - backend and management API implementation by @dimitar-shterev in #1294
Artifact Encryption
- Artifact Encryption plug point by @bogdan-bondar in #1202
Management API: New Resource Collection /rest/v1/actions
This new Management API feature provides read-only access to the collection of deployment actions via the context path "/rest/v1/actions". Furthermore, it allows you to filter this collection in a very flexible way by defining FIQL queries (request parameter 'q'). For example, you can define the following queries:
- Find all actions that match a certain action status (e.g. downloaded, finished, error, scheduled etc.).
- Find all actions that were spawned by a certain rollout.
- Find all actions that failed with a certain status code.
- Find all actions that refer to a certain distribution set.
So far, the collection of deployment actions could only be accessed for a specific target device ("action history"). With this new API, you can retrieve the data that is relevant for your specific scenario and feed it into your own custom UIs (e.g. dashboards) to monitor and troubleshoot your firmware updates.
- Add resource collection /rest/v1/actions to Management REST API by @stefbehl in #1299
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Add new endpoint for single action by @strailov in #1316
DDI-API: InstalledBase
Installed Base is a new feature which extends the DDI API with the "installedBase" endpoint that behaves similar to "deploymentBase" but instead of providing the latest on-going assignment, it provides the latest installed Distribution Set information. It can be used in multiple scenarios of a factory reset, device sync, etc.
DMF-API: Optional ControllerAttributes in THING_CREATED
The "attributeUpdate" property provides the attributes of the thing, for details see UPDATE_ATTRIBUTES message. This property is optional.
{
"name": "String",
"attributeUpdate": {
"attributes": {
"exampleKey1" : "exampleValue1",
"exampleKey2" : "exampleValue2"
},
"mode": "String"
}
}
- Optional controller attributes for THING_CREATED by @bogdan-bondar in #1154
UI Deep-Linking for Targets and Target Quicklinks in Management UI
To improve the usability of the Management UI of Eclipse Hawkbit, the target list views that are displayed on the Rollout and Target Filter views provide target quicklinks which take a user back to the Deployment view and, at the same time, select a specific target. This is useful if a user wants to take closer look at a certain target which is listed for a rollout group or target filter. By clicking the target quicklink, the user is taken back to the Deployment view and is immediately presented with the details of that specific target, in particular its action history.
The quicklinks are based on a new target deep-linking concept.
Example: <hawkbit-server-url>/UI/#!deployment/target=<target_id>
- UI deep-linking for targets by @bogdan-bondar in #1230
- Provide target quicklinks from Target Filters and Rollout views to Deployment view by @stefbehl in #1270
Support for Action Status Codes
This new feature enables targets to optionally include a status code into their action status feedback messages that are sent to Eclipse Hawkbit. The feature is supported via DDI and DMF. Annotating action status entries with status code simplifies the troubleshooting of software updates, e.g. by detecting error clusters matching a specific status code.
- Introduce action status scoped custom code by @herdt-michael in #1277
- Introduce action status scoped custom code - part 2 by @stefbehl in #1281
- Adding last action status code in view Rolloutgroup targets by @blomark in #1295
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Management API: Expose lastStatusCode property of action entities by @stefbehl in #1313
Management UI: Enhanced List Sorting
Various lists which are displayed in the different views of the Management UI can be sorted now by using the sorting controls that are exposed via the table columns. This is in particular useful for lists displaying many items. For example, a user might want to sort the targets of a rollout group based on their software update status to bring those targets with status 'Error' to the top of the list.
Contributors
Assets 2
0.3.0M7
New features
Required migrations ❗
- Database migration from master branch may fail for MSSQL, PostgreSQL and DB2 (#1080)
Consult the migration guide for support if you're affected
Enhancements
- Improved check whether a distribution set is valid (#1064)
- Show Controller ID within target, filter and rollouts view (#1056)
- DB and RabbitMQ integration tests and PostgreSQL testing/bug fixing (#1047)
- Fixed overriding deprecated method on NoCountPagingRepository (#1032)
- Improve Spring context holder registration in UI (#1026)
- Added triggeredBy for rollouts and autoassignment (#1017)
- Streamline hawkBit logout behaviour (OIDC vs. Credentials) (#945)
- Configure logoutHandler and logoutSuccessHandler as Beans (#938)
- Index on "last_modified_at" column in "sp_target" table (#1015)
- Sanitize ETag in S3 Repository (#66)
- Support for VScode and Azure Pipelines in extensions (#64)
- Update dependencies and tooling for Azure deployment (#57)
Version upgrades
- JDK 11 build support for hawkBit (#1037)
- Update Spring Boot to 2.3.7.RELEASE (#1018)
- Migrated Hawkbit UI to Vaadin 8 (#980)
- Update to Vaadin 8.11.3 (#1010)
- Increase cronutils version (#1053)
- JUnit5 support (#1063)
Bugs fixed
- Do not accept valid token headers by default (#1074)
- Fix NPE that occurs on invalid user input in editfields (#1077)
- DB migration scripts fixed for PostgreSQL, MSSQL and DB2 (#1061)
- Mgmt API error page vulnerable to cross-site scripting attack (#1067)
- Metadata UI permissions (#1035)
- Deregister UI remote event push strategy from application context (#1022)
- Not equal and out RSQL operator fixed (#935)
- Fix combobox initial selection (#1012)
- Roll-out-create failure with OIDC connect (#992)
- Custom filter refresh in management view (#970)
- UI references dead link (#962)
- Fix S3 Endpoint or Region configuration (#55)
Documentation
0.3.0M6
New features
- Mgmt API accepts and returns SHA256 file hash (#918)
- Introduce new DMF message THING_REMOVED (#891)
- OpenID Connect support (#865)
Enhancements
- Increase the value of maximal targets per auto assignment (#910)
- Check only DELETE_TARGET permission for deletion requests within target table (#909)
- Correct outdated RabbitMQ listener properties (#899)
- Prioritisation of assignments via Mgmt-API (#895)
- Fix upload quota check and provide better error message (#893)
- Add optional name to payload of thing created message (#888)
- Allow assignment of multiple distribution sets to a target via Mgmt-API (#886)
- Security fix for UI auto refresh (#885)
- Excluded EntityAlreadyExists exceptions from requeuing (#883)
- Ignore unknown properties on deserialisation of DDI-API model classes (#881)
- Remove dependency to Vaadin addon tokenfield (#875)
- Default sort order for targets and rollouts (#874)
- Return action IDs created by target-distributionset assignment (#864)
- Use browser locale for floating point numbers formatted String.format() in UI (#857)
Bugs fixed
0.3.0M5
New features
Enhancements
- Reduced DMF logging level in BaseAmqpService to debug (#868)
- Typos fixed in server error codes and messages (#867)
- Performance optimizations for Multi-Assignments (#858)
- Increase target name to 128 and target controller id to 256 (#849)
- Deployment type for Download-Only fixed on DDI-API (#848)
- Extend logic that marks DistributionSet as complete (#838)
- External reference for actions and status-update events (#830)