Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

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?

0 votes

Comments

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

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



2 answers

Permanent link
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).

1 vote

Comments

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.

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.

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?

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


Permanent link
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.


0 votes

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,036
× 562

Question asked: Jul 07 '14, 5:42 a.m.

Question was seen: 4,423 times

Last updated: Jul 07 '14, 10:23 p.m.

Confirmation Cancel Confirm