Skip to content

feat: Incremental Build#1267

Draft
RandomByte wants to merge 153 commits intomainfrom
feat/incremental-build-4
Draft

feat: Incremental Build#1267
RandomByte wants to merge 153 commits intomainfrom
feat/incremental-build-4

Conversation

@RandomByte
Copy link
Member

Implementation of RFC 0017 Incremental Build

This PR supersedes previous PoC: #1238

JIRA: CPOUI5FOUNDATION-1174

@RandomByte RandomByte marked this pull request as draft January 7, 2026 12:28
@coveralls
Copy link

coveralls commented Jan 7, 2026

Coverage Status

coverage: 99.566% (+4.9%) from 94.658%
when pulling b727ebc on feat/incremental-build-4
into cb29ec1 on main.

@RandomByte RandomByte force-pushed the feat/incremental-build-4 branch 3 times, most recently from 5224cd2 to 4904c84 Compare January 9, 2026 09:22
@RandomByte RandomByte force-pushed the feat/incremental-build-4 branch from 950fc6d to 41eed91 Compare January 14, 2026 15:28
@maxreichmann maxreichmann force-pushed the feat/incremental-build-4 branch from bb39565 to 2a21507 Compare January 20, 2026 10:01
@RandomByte RandomByte force-pushed the feat/incremental-build-4 branch 3 times, most recently from 6233816 to f858659 Compare January 20, 2026 16:58
@RandomByte RandomByte force-pushed the feat/incremental-build-4 branch from 71db1d0 to a2c371f Compare January 26, 2026 09:54
Cherry-picked from: SAP/ui5-fs@5651627
JIRA: CPOUI5FOUNDATION-1174
Cherry-picked from: SAP/ui5-builder@ef5a3b2
JIRA: CPOUI5FOUNDATION-1174
Prerequisite for versioning support

Cherry-picked from: SAP/ui5-project@83b5c4f
JIRA: CPOUI5FOUNDATION-1174
Cherry-picked from: SAP/ui5-cli@d29ead8
JIRA: CPOUI5FOUNDATION-1174
* Improve handling for concurrent resource access and modifications,
  especially when buffering streams.
* Deprecate getStatInfo in favor of dedicated getSize, isDirectory,
getLastModified methods.
* Deprecate synchronous getStream in favor of getStreamAsync and
  modifyStream, allowing for atomic modification of resource content
* Generate Resource hash using ssri
@RandomByte RandomByte force-pushed the feat/incremental-build-4 branch from 7364b4b to cf43f0c Compare February 9, 2026 13:32
maxreichmann and others added 6 commits February 10, 2026 10:37
… 'supportsDifferentialBuilds'

For better consistency
…-task project types (e.g. modules)

`+` Fix module test with now new assertions
´+´ style: Apply same line padding: (within a build stage: 1 empty line; between two build stages: 2 empty lines)
@maxreichmann maxreichmann force-pushed the feat/incremental-build-4 branch from 7da465c to 252b966 Compare February 16, 2026 17:14
@maxreichmann maxreichmann force-pushed the feat/incremental-build-4 branch from 252b966 to 874a943 Compare February 16, 2026 17:17
const test2JS = await workspace.byPath(`/resources/${projectNamespace}/test2.js`);

const tag = taskUtil.getTag(testJS, taskUtil.STANDARD_TAGS.IsDebugVariant);
if (!test2JS && testJS) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this if necessary? Both bodies seem identical

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, my only motive behind this was to have two seperate logic blocks (one for each build) and to have it consistent with custom-task-0.js (for easier understanding). But I'll refactor it to only one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 03d0f0e

} else {
// For #3 Build (NEW behavior expected as in #1):
if (tag) {
console.log("Tag set by custom-task-1 is present in custom-task-0 now, as EXPECTED.");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not expected. A task must never see tags only set by later tasks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tag for test.js is set by custom-task-1 in #1 Build.
In, #3 Build we then only touch test2.js, which skips execution of custom-task-1 (it's not an input of it). But should custom-task-0 still not be able to see the tag? What's then the purpose of the cache?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to make sure that tasks always behave the same, no matter whether other tasks are skipped (by using a valid cache) or not.

This means that a custom-task-0, which can't find a tag for resource test.js in the first build, must never find a tag for that resource in any other build.

Otherwise you could end up with different build results, depending on whether you build your project with or without cache. This must to be avoided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it now. That's definitely the right way.
I'll refactor the tests now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 03d0f0e

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.

4 participants

Comments