New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove ArchUnit FreezingArchRule as it unstable to skip line numbers and any other extra changes #14053
Comments
This diff is good example that file is just snapshot of our current dependencies of packages. So not only changes in line numbers, in signatures of methods. BUT also new line might appear. So I propose to: |
@romani doesn't only one test in https://github.com/checkstyle/checkstyle/pull/14009/files#diff-a976ae03b947162410f0c24b8a0892a6b4410b110c297dfee26878446137c367R6 depend on a file being checked in? Can we enable the other tests?
This really doesn't address my main concern from #14009 (comment); I feel that having a unit test modify some file that is checked in is confusing for contributors; manual copying of files only exacerbates this issue. Is it possible for us to simply have some number of violations that lives in the test itself (not an external file), and we just make sure that this number never increases? |
yes, I thought that all of them use it, my bad.
Confusion of contributors happening by any violation or CI failure. As we move file out or git monitoring, it will not be a problem as we suppose to fail only if new cycle is introduced. But yes, if new cycle appeared, it will not easy to resolve for contributors and they will need help of maintainers. If cycle is not required, we will show how to fix code to avoid it. If cycle is not avoidable, maintainers will guide how to update this file.
goal it archive a state when it is required in very rare cases when new cycle is approved, unfortunate but approved. In all other cases dependency files will stay as is. It will be stale, very outdated but arch unit will update it and I hope will fail only if new cycle is created. If this is not going to work. We need to disable/remove it completely as it is not usable/practical validation. |
@romani what about proposal from above:
We can just check how long the generated file is (or maybe not even generate a file) and keep this number of violations in the test only. This way we make sure that we don’t add to violations until we are ready to start breaking cycles. |
I have problem to reproduce any violation by this test :)
by command:
|
I see no violations for now at all. |
@Vyom-Yadav , do you remember why our validation doesn't detect cycles? See log above |
Test is still disabled in master. checkstyle/src/test/java/com/puppycrawl/tools/checkstyle/internal/ArchUnitCyclesCheckTest.java Line 33 in 11e2b4b
|
I put a lot of details to #14060, I do not think we can easily use this Rule now. |
@romani are we done here? |
I planned to open new PR, to do it in "correct way " at least as they wanted it to be, to open issue on them. |
Based on discussion at #14009
It becomes clear that validation of cycles by ArchUnit FreezingArchRule has problems due to fact that base file that we store in our git repo contains line numbers.
Example:
checkstyle/config/archunit-store/slices-should-be-free-of-cycles-suppressions
Line 10 in 76a65e1
and almost each change in files that referenced in this suppression, results in no problems in ArchUnit validation as it skipped by design.
According to the docs, it should be:
BUT, as we store this file in git, this file is changing, and our CI detects not committed changes and failing.
We need to update execution of test method that triggers validation and update of this file to have post validation update on file to remove or substitute to dummy
0
value for line number.If approach above is not going to help, we need to disable this validation as we do not know how to freeze old problems and only update this file if we agree to extend our cycles. We should not update this file at any other case.
Referenced PR is example how to activate back validation and play with extra updates to such file.
The text was updated successfully, but these errors were encountered: