Feature suggestion: Freeze files and stored.rules validation / sanity check #1264
Comments
|
Sorry for the late reply, I think it would be a nice addition, if anybody wants to give this a shot I would support it! In the past we've already sorted the actual violations alphabetically to ease human browsing and diffs if I remember correctly. |
|
Hello 👋 |
Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
delete empty rule violation file Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
warn on empty rule violation file Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
warn on empty rule violation file delete empty rule violation file Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
warn on empty rule violation file delete empty rule violation file Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
|
I have created #1405 which solves parts of the features requested above, request no. 2 to be specific.
If those changes make sense to you I can proceed and update the docs in the same PR. |
|
I can work on the following feature requests in another PR
The 4th request
|
These changes introduce two new features for FreezingRule default store * Raise error when a freezing rule has zero violations. This can be enabled by setting the property `default.warnEmptyRuleViolation=true`. For backward compatibility it is disabled by default. * Skip rule violation file creation or delete if it already exists, when there are zero violations. This can be enabled by setting the property `default.deleteEmptyRuleViolation=true`, it is disabled by default. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
* clean up of frozen rules in `stored.rules` where the corresponding file does not exist in the store directory * clean up of files in store directory which are not referenced in `stored.rules` file Both of the above operations are enabled using `default.allowStoreUpdate` property. If `default.allowStoreUpdate=false` and obsolete entries or files are found by either of the above operations, the operation fails with an `StoreUpdateFailedException`. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
* clean up of frozen rules in `stored.rules` where the corresponding file does not exist in the store directory * clean up of files in store directory which are not referenced in `stored.rules` file Both of the above operations are enabled using `default.allowStoreUpdate` property. If `default.allowStoreUpdate=false` and obsolete entries or files are found by either of the above operations, the operation fails with an `StoreUpdateFailedException`. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
* clean up of frozen rules in `stored.rules` where the corresponding file does not exist in the store directory * clean up of files in store directory which are not referenced in `stored.rules` file Both of the above operations are enabled using `default.allowStoreUpdate` property. If `default.allowStoreUpdate=false` and obsolete entries or files are found by either of the above operations, the operation fails with an `StoreUpdateFailedException`. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
* clean up of frozen rules in `stored.rules` where the corresponding file does not exist in the store directory * clean up of files in store directory which are not referenced in `stored.rules` file Both of the above operations are enabled using `default.allowStoreUpdate` property. If `default.allowStoreUpdate=false` and obsolete entries or files are found by either of the above operations, the operation fails with an `StoreUpdateFailedException`. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
|
I created #1407 for addressing requests no. 1 and 3. If those changes make sense to you I can proceed and update the docs in the same PR. |
These changes introduce two new features for FreezingRule default store * Raise error when a freezing rule has zero violations. This can be enabled by setting the property `default.warnEmptyRuleViolation=true`. For backward compatibility it is disabled by default. * Skip rule violation file creation or delete if it already exists, when there are zero violations. This can be enabled by setting the property `default.deleteEmptyRuleViolation=true`, it is disabled by default. Signed-off-by: Masoud Kiaeeha <[email protected]> Resolves TNG#1264
|
It's great to see that there is progress here. Thank you very much. Regarding empty freeze files. In our company we have several parameterised tests where we freeze by default. As adding new parameters in our case probably also needs freezing. |
I've taken this approach in my PR #1405 . If the new property In our company we're facing empty freeze files for a different reason. We have centrally defined our archunit test set in a library. Some of our tests are freezing because they enforce rules that can be broken in exceptional cases, e.g. use of deprecated classes is allowed for short period to allow enough time to update the code. When we run our archunit tests in different services we get different results, in many cases empty violation files. With these changes I intend to get rid of those empty files. |
Hi ArchUnit Team,
First of you do a great job here. ArchUnit is great.
In our project we currently have >70 freeze files in the stored.rules mentioned.
Digging deeper I noticed several things, which I am concerned about.
Of course in the end it is our job to keep our source code in check and clean up correctly etc.
Yet I wonder how ArchUnit itself can help to have a sanity check of its freeze files and stored.rules?
What is your opinion on this?
The text was updated successfully, but these errors were encountered: