test(monitoring): the build assertion names the configured product - #6756
Merged
Merged
Conversation
MonitoringShellIT asserted that the sidebar's build line contains the literal "Eclipse Dirigible". That element is rendered from DIRIGIBLE_PRODUCT_NAME via /services/core/version, so a rebranded assembly correctly names its own build there and the assertion can never hold for it. This matters because tests-integrations lives in src/main precisely so the jar publishes and downstream editions can reuse these ITs; the codbex editions run MonitoringShellIT through a @suite, where it has been failing on every build. Assert the configured product name instead. Stock CI is unchanged - project.title is "Eclipse Dirigible" in the root pom and is filtered into build/application's dirigible.properties, so the expected text is the same literal as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
MonitoringShellIT.systemNamesTheDeployedBuildasserted a product-name literal:That element is rendered from
DIRIGIBLE_PRODUCT_NAME, read through/services/core/version. A rebranded assembly therefore names its own build there — correctly — and the assertion can never hold for it.This is not hypothetical.
tests/tests-integrationslives insrc/mainspecifically so the jar publishes to Maven Central and downstream editions can reuse these ITs, and they do: the codbex editions runMonitoringShellITthrough a@Suiteof ~26 upstream ITs. codbex-atlas setsDIRIGIBLE_PRODUCT_NAME=${project.title}→codbex atlas, so this single test has been red on itsmainsince at least 14.24.0:The UI was already edition-aware — the
versionstore resolves an unfiltered${...}placeholder to empty, and its own docstring cites a rebranded example ("BusinessIntents Suite 2.98.0"). Only the test wasn't.The change
Assert the configured product name rather than the literal:
Stock CI coverage is unchanged.
project.titleisEclipse Dirigiblein the root pom and is filtered intobuild/application/src/main/resources/dirigible.properties, soConfiguration.getreturns exactly the literal that was hard-coded before — the same assertion, sourced from where the UI sources it.Configurationis already used by four other ITs in this module, so no new dependency.The test's intent is "the System page names the deployed build", not "the build is Eclipse Dirigible".
Verification
MonitoringShellITrun headless against a full local build of this branch:formatter:validatepasses.Note for downstream editions
Separately, codbex-atlas#431 adapts that edition to #6735, which moved six Camel ITs from
...ui.tests.camelto...api.cameland broke its release build attestCompile. Both cases are the same underlying point: this module is a published API for downstream editions, so an IT rename, move, or brand literal is a breaking change for them.🤖 Generated with Claude Code