It's all about the answers!

Ask a question

RTC Upgrade v 4.0.5 - Initial build = full build ?


Kenneth Munch (13522124) | asked Jan 23 '14, 4:38 a.m.
We have just migrated RTC from v 4.0.3 to 4.0.5.
Everything works as expected, but when running a given build for the first time since the migration, it runs a full dependency build instead of a delta.
I guess it can be explained, since the buildsystem toolkit is also new ?

3 answers



permanent link
Daniel Bruce (9135) | answered Jan 23 '14, 9:07 a.m.
JAZZ DEVELOPER
Hi Kenneth,
Actually for a small upgrade from RTC 4.0.3 to RTC 4.0.5 performing a full dependency analysis for a non initial build is unexpected.  Can you provide the statements from the beginning of the build result including the statement stating that a full analysis is being performed?  Often times a reason is given for why full dependency analysis is being performed.

Regards,
Dan Bruce

permanent link
Kenneth Munch (13522124) | answered Jan 24 '14, 3:07 a.m.
Hi Daniel. This is what we've got from the build log:

Found a user request for build definition ERP.Sandkasse.TESTENV.Dependency.build.TEAM
Substituted the following build property variables:
Substituted the following configuration element property variables:
Should build occur?
Yes: Always build a user initiated request.
The JAZZ_USER build property is not specified.  The build pre-processing code will be running under the ADMIN user ID.  If you wish to run the build pre-processing code under a user ID other than ADMIN, define the JAZZ_USER build property either in your build engine or your build definition.
Accepting changes into workspace "ERP Sandkasse TESTENV Stream Dep Build Workspace"...
System definition S36RPG has changed. Dependency set comparisons will be performed.
One or more entries in the buildComponents.xml file has changed since the last successful build.  Dependency set comparisons will be performed.
Performing full dependency analysis
System definition S36RPG has changed. Dependency set comparisons will be performed.
One or more entries in the buildComponents.xml file has changed since the last successful build.  Dependency set comparisons will be performed.
The dependency set for CERTI10.LF has changed. This file will be rebuilt.
The dependency CERTI for CERTI10.LF has changed.
The dependency set for S4950S0005.DSPF has changed. This file will be rebuilt.
The dependency SANIREF for S4950S0005.DSPF has changed.
The dependency set for W4971APF.PF has changed. This file will be rebuilt.
The dependency SANIREF for W4971APF.PF has changed.
The dependency set for W4971APF.PF has changed. This file will be rebuilt.
The dependency SANIREF for W4971APF.PF has changed.
..
"The dependency set for", and "The dependency SANIREF for xxxxxx has changed." continue for all members

permanent link
Daniel Bruce (9135) | answered Jan 24 '14, 11:04 a.m.
JAZZ DEVELOPER
Hi Kenneth,
The clue is in this line in the log:

One or more entries in the buildComponents.xml file has changed since the last successful build.  Dependency set comparisons will be performed.

What this means is that the build detected a change to one or more system definitions (i.e. language definition, translator, data set definition) that were used in the current build when compared to the last successful team build.  If you were to go to the downloads tab and get the buildComponents.xml file and compare it to the same file from the previous successful team build, that would show you which system definition had changed. Changes to a system definition may have an impact on one or more files in the build workspace which may result in the file needing to be rebuilt even if the file itself or a dependency file has not changed.  So dependency set comparisons are performed on all files in the build workspace to see if any need to be rebuilt, hence the full dependency analysis.

Truth is though most of the time these changes to a system definition do not result in any files needing to be rebuilt even after dependency set comparisons have been performed.  Unfortunately we currently do not have the ability to automatically determine which changes can safely be ignored in a system definition.  But we have provided two different mechanisms that you can manually set to avoid full dependency analysis because of changes in system definitions.

1) You can check the "Ignore changes to this system definition during a dependency build" checkbox on any or all of your system definitions.  The description says it all.  :^)

2) You can add a build property called "team.enterprise.build.dependency.forceChangeSetAnalysis" and set it to "true" to your build definition.  This is a little more dangerous because it forces the dependency build to perform a change set analysis even if certain conditions would normally cause a full dependency analysis to occur.  This may result in some files not building that should have.  Even with this property set, there are still conditions that will cause a full dependency analysis (like an initial build) but a message in the build log will explain why the property was ignored.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.