Skip to content

test(monitoring): the build assertion names the configured product - #6756

Merged
delchev merged 1 commit into
masterfrom
fix-monitoring-build-product-name
Aug 16, 2026
Merged

delchev merged 1 commit into
masterfrom
fix-monitoring-build-product-name

Conversation

@delchev

@delchev delchev commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

The problem

MonitoringShellIT.systemNamesTheDeployedBuild asserted a product-name literal:

browser.assertElementExistsByIdAndContainsText("monitoring-build", "Eclipse Dirigible");

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-integrations lives in src/main specifically so the jar publishes to Maven Central and downstream editions can reuse these ITs, and they do: the codbex editions run MonitoringShellIT through a @Suite of ~26 upstream ITs. codbex-atlas sets DIRIGIBLE_PRODUCT_NAME=${project.title}codbex atlas, so this single test has been red on its main since at least 14.24.0:

DirigibleCommonTestSuiteIT.systemNamesTheDeployedBuild
  Element by [By.id: monitoring-build] and conditions
  [[exist, match text "\QEclipse Dirigible\E"]] cannot be found in any iframe.
Tests run: 45, Failures: 1

The UI was already edition-aware — the version store 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:

browser.assertElementExistsByIdAndContainsText("monitoring-build", Configuration.get(DIRIGIBLE_PRODUCT_NAME));

Stock CI coverage is unchanged. project.title is Eclipse Dirigible in the root pom and is filtered into build/application/src/main/resources/dirigible.properties, so Configuration.get returns exactly the literal that was hard-coded before — the same assertion, sourced from where the UI sources it. Configuration is 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

MonitoringShellIT run headless against a full local build of this branch:

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.91 s
  -- in org.eclipse.dirigible.integration.tests.ui.tests.MonitoringShellIT
BUILD SUCCESS

formatter:validate passes.

Note for downstream editions

Separately, codbex-atlas#431 adapts that edition to #6735, which moved six Camel ITs from ...ui.tests.camel to ...api.camel and broke its release build at testCompile. 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

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>
@delchev
delchev merged commit b1585b3 into master Aug 16, 2026
10 checks passed
@delchev
delchev deleted the fix-monitoring-build-product-name branch August 16, 2026 10:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant