Before REST refactoring MgmtBaseEntity was able to deserialize fields
like createdBy. After refactoring, with READ_ONLY access it was dropped
and these fields become null. While this could be a good change, it is
not backward compatible (is that needed) and most importantly will lead
to the fact that Feign client won't be able to access that
data. So, at least for now, I return deserialization back
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Tenant
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* REST doc / Mgmt Target Tag - fix missed info
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Tag
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* REST doc / Mgmt Target Type - fix missed info
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Type
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Tag
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Targets
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - TargetFilters
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - SoftwareModules Types
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - SoftwareModules
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Rollouts
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSetsTags
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSetsTags
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSets
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Actions
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for DDI API
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1383] Spring Boot 3 migration Step 2
Some of the steps:
1. Change spring version parent and versions in root pom.xml
2. update eclipselink versions
3. javax.annotation -> jakarta.annotation (*.java)
4. javax.persistence -> jakarta.persistence (*.java)
5. javax.servlet -> jakarta.servlet (*.java, pom.xml)
6. javax.validation:validation-api -> jakarta.validation:jakarta.validation-api (pom.xml)
7. javax.validation -> jakarta.validation (*.java)
8. javax.transaction -> jakarta.transaction (*.java)
9. replace spring-cloud-stream-binder-test (hawkbit-repository-test) with
```
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-test-binder</artifactId>
</dependency>
```
, TestSupportBinderAutoConfiguration.class }) -> })
@Import(TestChannelBinderConfiguration.class)
10. Set to Simple UI standard parent
11. requestMatchers to securityMatcher
12. @SpringBootApplication(scanBasePackages = "org.eclipse.hawkbit") (otherwise for instance flyway doesn't work - suffix is default ".sql", not H2.sql and don't differentiate dbs? strange is there a change?)
13. @NonEmpty for Long leads to validation exception - replaced with @NotNull
14. RSQLUtilityTest.correctRsqlBuildsPredicate - fixed - mock query builder add method
15. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#spring-mvc-and-webflux-url-matching-changes - aliases as targers/ return 404 - remove trailing slash
16. firewall tests (allowedHostNameWithNotAllowedHost) doesn't throw 'rejected exception' but return 400 instead (as probably is expected anyway)
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com
* Fix tenant listing to do not mix with multitenancy
Tenant metadata is not multitenancy aware while depend on distribution set type
which is. Thus querying all tenant metadata (in non tenant context) sometimes leads to
resolution of distribution set type which is tenant scoped and leads to problems.
So, now listing tenant lists just their ids - not fill entities.
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1548] Add support for dynamic rollouts
-- Current status --
Initial draft only !!!, to be improved
TODO:
* evaluate the target count - if update group/rollout total count fails dynamic updates could (?), actually, contain more targets
* is it needed to break handler on group creating?
* if dynamic group schedulers occur to be heavy - maybe a handler per tenant will ensure that one tenant won't break all
*Concept for dynamic groups*:
Rollouts are static and dynamic.
Static rollouts consist of static groups only while dynamic rollouts have a number of static groups (first groups) and then an unlimited number of dynamic groups.
Group targets assignments:
* static groups include ALL matching targets created at the time the rollout was created, nevertheless they have active actions with bigger weight or not. Actions for the rollout and included targeets however are created at the start time.
* dynamic groups however are filled in when started and consider the action weight. The targets included in a dynamic group are:
* matching (filter and distribution set compatible)
* not included in this or following rollout static groups (if already included in any of the following rollouts - it's intended to be overridden)
* not in active actions of any rollouts with equal or bigger weight
In general, when you create a rollout it contains all matching targets available at create time overriding any previous rollouts, actions, and so on. If the rollout is dynamic when its dynamic group becomes running it gets only matching targets that doesn't belong to static groups or have actions with great or equal weight
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1548] Add 1000 weight for actions, rollouts and auto assignments without weight
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* Introduce request parameter to request download URLs when retrieving list of artifacts for a specific software module.
* Fix DDI integration test by aligning download path to new config
* Make use of mgmt representation mode in sw-module mgmt api
* Changed path
* refactor test names
* Expose forceTime and startAt fields in rollout representation in Mgmt API
* Change "forceTime" to "forcetime"
* Add checks when making a POST request in the tests
* Change forced to timeforced in tests and extend validity check
* Pass aforcetime and startat arguments as test checks
* remove unused import
Signed-off-by: Stanislav Trailov <stanislav.trailov@bosch.io>
* Add new endpoint for single action
* Adding the new endpoint to the documentation
+ reverse the representation mode to FULL
Signed-off-by: Stanislav Trailov <stanislav.trailov@bosch.io>
* Introduce user consent flow
* Add permissions to confirmation management
* rename from consent to confirmation
* Reformat code. Remove unused imports. Change and add permission checks when configuring auto-confirmation.
* Do not include null values for DDI confirmation base endpoint
* fix confirmation required checkbox id
* Remove unused import. Fix consume/produce type of new API's.
* Change term processing to proceeding when activating user consent flow
* Align formatting and extend integration test cases for DMF and DDI.
* Extend DMF test cases to consider auto-confirmation
* Refactor action management to fix problem of handling action status updates on closed actions.
* remove unsupported validation
* use new confirmation api for DMF. Extend test cases.,
* Remove unnecessary fields.
* Extend API documentation for DDI and MGMT API.
* adapt ddi api docs adoc file
* Fixed the duplicate migration version for db files
* fix method to support confirmation
* Fixed PR comments
* Addressed PR comments
* Fixed after merge compilation issue
* Fixed after merge compilation issue
* Fix failing tests in MgmtRolloutResourceTest
* Fixed the permissions issue reflected by integration tests
* Added back the missing line of code lost during merge
* Fix the failing test on Jenkins
Signed-off-by: Stanislav Trailov <stanislav.trailov@bosch.io>
Signed-off-by: Dimitar Shterev <dimitar.shterev@bosch.io>
Signed-off-by: Michael Herdt <Michael.Herdt@bosch.io>
Signed-off-by: Shruthi Manavalli Ramanna <shruthimanavalli.ramanna@bosch-si.com>
Co-authored-by: Shruthi Manavalli Ramanna <shruthimanavalli.ramanna@bosch-si.com>
* Trigger next rollout group - backend and management API implementations. Backend and management API tests.
* Trigger next rollout group - Fixed resource documentation test.
* Trigger next rollout group - Fixed resource documentation test.
* add rest docs
* Trigger next rollout group - UI changes. New button for trigger next rollout group in rollout view.
* add error test for rest api
* Trigger next rollout group - Added test for triggering next group for all rollout states.
* add confirm
* fix test
* replace DB calls
* fix translation
* fix error message
Signed-off-by: Dimitar Shterev <dimitar.shterev@bosch.io>
Signed-off-by: Stefan Klotz <stefan.klotz@bosch.io>
Co-authored-by: Stefan Klotz <stefan.klotz@bosch.io>
