Include module core-its
#2315
Include module core-its
#2315
Conversation
Pankraz76
force-pushed
the
fix-write-test-add-module-its
branch
from
825c30c to
6401e5a
Compare
|
wip |
There was a problem hiding this comment.
The its are activated in a profile.
This could be a good idea, but I don't think the default config would use the distribution built earlier in the build, bur rather the distribution used to actually build maven. If you find a way to fix that, that would be nice.
As to wether ITs should be activated by default, it would be doable, but the CI scripts would have to be adjusted, and we'd need a way to not include then (i.e. turn the profile to activate the ITs unless a property is set, or something like that).
There was a problem hiding this comment.
The its are activated in a profile.
This could be a good idea, but I don't think the default config would use the distribution built earlier in the build, bur rather the distribution used to actually build maven. If you find a way to fix that, that would be nice.
As to wether ITs should be activated by default, it would be doable, but the CI scripts would have to be adjusted, and we'd need a way to not include then (i.e. turn the profile to activate the ITs unless a property is set, or something like that).
|
Please refrain from raising PRs when you have questions. Just go on slack and ask there, there will be plenty of people to answer questions. |
|
Assuming the tight build time has only increased by a few seconds, it seems that nothing has changed except for including the project, making it directly visible in the Project Explorer. Since these are integration tests, they should not be excluded by default due to resource limitations. I just mean—try the CI build. It shouldn't break anything and will only slightly increase the local build time by a few seconds.
|
|
might consider folder alignment as follow up: 
|
|
I actually don't like folder alignment proposal. |
Why Should Developers Run This High-Intensity Task? Its excluded in dedicated profile, like expected for good reason. Intent:
Key Points:
Our Approach:
|
Whats the matter? Current Problems:
Assessment:
Key Argument:
|
|
I agree with consistency. That does not necessarily mean aligning directory structure with artifact id. |
Project Alignment & StructureThe current setup shows about 95% alignment with standards - significantly better than most projects. The conventions and configuration practices are well implemented, though perfect adherence isn't critical. Priority: Module Structure ClarityWe should focus on making the module structure immediately understandable: Current Challenges
Proposed Improvements
|
|
its possible, having only small benefit yes, but idk why we should hide the code. its there, lets admin and embrace. |
That' an IDE problem. It hinders ease of navigation in the console for example. Going to a subdirectory or building a subproject needs more typing because the completion with tab in your shell cannot complete directly. You first need to autocomplete the unambiguous part for example.
|
Again I'm fine if we can make the ITs also run. ITs have been merged into the core project only a few months ago, they were in a separate git repo for ages. |
yes, this the next step imho to have clear history. But still it will be the same like now clean install basically just compiling. No one will ever run these on daily bases due to heavy load. If they run now on some cloud they should run everywhere. its dedicated concern. I will run locally then we can go on. |
|
This is flaky since beginning: 
|
|
item:
[ERROR] Tests run: 977, Failures: 1, Errors: 11, Skipped: 160 
it takes 9 mins as expected even if build success makes no difference because this it designed to run online on large scale only for dev on subset locally. But this is different topic. considering MakeItWorkMakeItRightMakeItFast merging it. then trying to go the next step. How is it working ATM are there 2 versions? A working setup should be assumed for such high critical system. https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast log: |
|
wip reopen when ci green |
There was a problem hiding this comment.
Adding ITs to the build is wrong, unless they can actually run with the being built assembly. The argument about avoid possible compilation breakage is wrong, as the ITs don't use the jars that are being built, but much older versions usually.
Please fix the first point or abandon the idea. The second point should not be attempted at this point, as the policy is not to upgrade ITs to latest dependencies, but only test with the latest maven.
|
thanks for info. |
enabler for:
Java 21- infrastructure #2319I wonder why it’s not included. I was thinking about this, assuming it might be related to integration tests—and it turned out to be true.
Why not provide this information upfront?
If it’s resource-intensive, it should only run in a dedicated stage.
Ignore whats actually there seems strange:
useit orlooseit.