History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-2550
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Robin Shen
Reporter: Phong Trinh
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
QuickBuild

QuickBuild hasPerforce Sync/checkout isssue

Created: 02/Oct/15 01:13 AM   Updated: 18/Aug/20 10:39 PM
Component/s: None
Affects Version/s: 6.0.21
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: None
Image Attachments:

1. Build_Overview.PNG
(15 kb)

2. New-Build.PNG
(41 kb)

3. Perforce_CLs.PNG
(7 kb)

4. Previous_Build.PNG
(39 kb)
Environment: Linux


 Description  « Hide
  Hi Support Team,

 QuickBuild has an issue when syncing files from Perforce to QB workspace. Our continous integration build syncs to head of the change list, and it builds when changes found in the referenced repository. The issue is as the follow:
 There was build which was synced to CL number 652498. Later there were several submissions into perforce branch, and their CL numbers were 652508, 652520, 652530, and 652536. Then the build was triggered and it synced to CL 652536, since this CL was the head CL at this point of time. Looks like QB didn't sync the updated files in CL 652508 and CL 652520 down to the workspace, since QB didn't list them in the SCM changes. I attached the screenshots of these builds and Perforce Change lists for your references.


 Thanks,
ptrinh

 All   Comments   Work Log   Change History      Sort Order:
Robin Shen [03/Oct/15 12:48 AM]
This is because the revision of previous build of "CL#652536" is actually "652520", instead of 652548. To verify this, you may switch advanced setting of the configuration, and add a custom build column displaying value:
${repositories.get("your repo name").revision}



Phong Trinh [05/Oct/15 02:08 PM]
I am not sure I understand your comment, since the previous build was "CL652498", and its the revision was 652498. This revision number was in Source.revision file as well. The next build should sync the all of the changes in CLs: 652508, 652520, 652530, and 652536, but it didn't. It synced only the changes of CL 652530, and 652536 and skipped the CLs 652508, and 652520 as you saw in the screenshots. The committers of CLs 652508, and 652520 never received notification email too.

Robin Shen [05/Oct/15 10:35 PM]
Although the the revision number is displayed as CL652498, it is possible that the internal revision has been changed afterwards via repository.setRevision(...) (for instance your custom script calls this to move to another revision for checkout). So I suggest to add that column to display the actual revision recorded in QB for previous build.

Phong Trinh [06/Oct/15 03:33 PM]
I think I may need to clarify on this issue:
- I do not have any custom script which is making any change to the revision. I specify the build number of our build: CL#${repositories.get('Source').revision} and use the built-in: Repositories->Checkout.
- QB listed SCM changes in build: CL#652498 properly. The following build synced to the head revision which was CL 652536. This build should list all of SCM changes since last build which were in 652508, 652520, 652530, and 652536; however, QB listed only the changes of 652530 and 652536. Our developers and testers need to know what changes go into what build by looking at the SCM changes of each build, so they can test or do analysis. Since QB doesn't list or sync the changes properly, it could be a big issue to us.
- I will add a custom build column displaying value: ${repositories.get("your repo name").revision} , but I think it is duplicate of build version which I currently have.

Robin Shen [07/Oct/15 12:02 AM]
Please add that custom column just in case there are some unexpected changes in this regard.

Phong Trinh [18/Aug/20 08:02 PM]
Thanks. Please close this issue. I will open a new one if i see this issue again.