It's all about the answers!

Ask a question

Personal build issue when setting team.scm.deleteDestinationBeforeFetch to false?


Makson Lee (41024241) | asked Jul 07 '14, 5:42 a.m.
If we set team.scm.deleteDestinationBeforeFetch to false, then try to request two personal builds against one same build definition with two different workspaces, workspace A and workspace B in order, the files existing only in workspace A would not been removed when requesting the second build, is this normal behavior?

Comments
sam detweiler commented Jul 07 '14, 7:14 a.m.

does the 1st build start before u request build 2?


Makson Lee commented Jul 07 '14, 8:02 a.m.

Actually, i request build 2 after build 1 is complete.

2 answers



permanent link
Makson Lee (41024241) | answered Jul 07 '14, 9:49 p.m.
edited Jul 07 '14, 10:23 p.m.
The real case is, we are working with Android source code, and we create load rules according to https://jazz.net/library/article/1196, i am not sure if we can still tune the load rule to meet the requirement.



permanent link
Heather Fraser-Dube (4512) | answered Jul 07 '14, 7:57 a.m.
JAZZ DEVELOPER
If Workspace A had any top level elements loaded that are not in Workspace B, then they would remain.
Example:
Workspace A has component X and Workspace B does not. Component X remains loaded.

Workspace A has component Y with top level item Z loaded (a share) and Workspace B has component Y but Z is not a top level item to be loaded from it.

The build is trying to not interfere with other steps you might have to load from other places (i.e. loading of tools used to build from the repository).

Comments
Makson Lee commented Jul 07 '14, 8:12 a.m.

My case is really simple, one component, with three change sets (A, B, C), each change set introduces a new file, test1.txt test2.txt test3.txt in order, workspace A contains all the change sets, workspace B contains only change set A, request build 1 with workspace A, and then request build 2 with workspace B, now, i suppose only test1.txt exist in the local sandbox on build machine, but the truth is, test2.txt and test3.txt are there too.


Heather Fraser-Dube commented Jul 07 '14, 8:35 a.m.
JAZZ DEVELOPER

Depends on what are the roots being loaded. I am assuming you are not using loadrules to restrict what is loaded. If your component looks like:

/MyTopFolder
/MyTopFolder/test1.txt
/MyTopFolder/test2.txt
/MyTopFolder/test3.txt
and you don't have any load rules to restrict what is being loaded, then /MyTopFolder is what is loaded and test2.txt and test3.txt should not be there

If your component looks like
/test1.txt
/test2.txt
/test3.txt
And no load rules then all 3 files are top level items (shares) being loaded and test2.txt and test3.txt would remain since they are shares from a different workspace.

If you wanted to treat the component's root folder as the share, you would need to use a load rule and load it as the top level item.


Makson Lee commented Jul 07 '14, 9:39 a.m.

My component looks like this,
/test1.txt
/test2.txt
/test3.txt
so is there any way to make sure that each personal build with different workspace just load the files the workspace have, no more, no less?


Heather Fraser-Dube commented Jul 07 '14, 2:49 p.m.
JAZZ DEVELOPER

You would need to use a load rules. Specifically you need an ItemLoadRule to load the component root directory. See https://jazz.net/library/article/1015

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.