Skip to content

Add regression tests for buildThemes per-theme delta builds - #1609

Merged
matz3 merged 5 commits into
mainfrom
test/buildthemes-theme-delta-tests
Sep 24, 2026
Merged

matz3 merged 5 commits into
mainfrom
test/buildthemes-theme-delta-tests

Conversation

@matz3

@matz3 matz3 commented Sep 23, 2026 •

Copy link
Copy Markdown
Member

Preparatory work for the task system rework: adds failing/regression tests for buildThemes per-theme delta builds, plus the task-end written-resource-paths event they rely on.

Also converts the sap.ui.core fixture in the generateLibraryPreload staleness test from type: module to a normal type: library dependency (Follow-up of #1606).

JIRA: CPOUI5FOUNDATION-1363

Extend ProjectBuild#endTask to accept and emit an optional
writtenResourcePaths field on the ui5.project-build-status "task-end"
event. This exposes which resources a build task wrote, a finer-grained
build-observability signal than the existing task-start/task-skip
status. Backward compatible: the field is undefined when omitted.
ProjectBuildCache#recordTaskResult now returns the already-computed set
of resource paths written by the task (previously discarded). TaskRunner
passes it into ProjectBuild#endTask so it is emitted on the
ui5.project-build-status "task-end" event.

This makes "what did a task write" observable to build-status listeners
(e.g. integration tests), which is a more precise signal than task-level
skip tracking for reasoning about delta-build correctness.
buildThemes does not support differential builds, so any tracked-input
change re-runs the whole task and rewrites every matched theme. When a
theme-library is built as a dependency, its librariesPattern filter
builds a library's theme only if a library.js/.library marker is
available. Adding or removing such a marker should (re)build or remove
exactly one theme and leave the others served from cache.

Add two test.serial.failing cases asserting this desired per-theme delta
behavior via the new task-end writtenResourcePaths signal, plus a
FixtureTester helper (addMultiLibraryThemeLibraryDependency /
setMultiLibraryThemeLibTwoMarker) that injects a theme-library shipping
themes for two library namespaces. The tests fail today because the task
rebuilds all themes; closing the gap is future work.

Also consume writtenResources in the fixture tester's assertions.

JIRA: CPOUI5FOUNDATION-1363.
Serving a theme-library whose library.source.less @imports the base theme
LESS of a dependency control library must serve fresh CSS after that base
LESS changes, without a server restart: buildThemes resolves the @import
through its workspace+dependencies combo, so the cross-project dependency
read must re-drive the task when the imported base LESS changes.

This scenario passes on main; the test guards the current cross-project
@import invalidation behavior against regression.

JIRA: CPOUI5FOUNDATION-1363.
@matz3
matz3 requested a review from a team September 23, 2026 11:30
…test

The generateLibraryPreload core-version staleness test built its
sap.ui.core dependency as a type: module. generateLibraryPreload reads
only the current project's own workspace, never the dependencies reader,
so the core's built resource content is not an input to a depender's
preload -- the version reaches the output solely through
getProject("sap.ui.core").getVersion(). A normal type: library core dep
therefore does not mask the signature gap, so the test stays a valid
expected-failure while using a more realistic fixture.

Use the default src/ folder (dropping the paths.src config).

JIRA: CPOUI5FOUNDATION-1363
@matz3
matz3 merged commit b2d45a6 into main Sep 24, 2026
78 checks passed
@matz3
matz3 deleted the test/buildthemes-theme-delta-tests branch September 24, 2026 09:08
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.

2 participants