| << Back to previous view |
|
[QB-2550] QuickBuild hasPerforce Sync/checkout isssue
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 6.0.21 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Phong Trinh | Assigned To: | Robin Shen |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Environment: | Linux | ||
| File Attachments: |
Build_Overview.PNG
New-Build.PNG
Perforce_CLs.PNG
Previous_Build.PNG
|
| Description |
|
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 |
| Comments |
| Comment by 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} |
| Comment by 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. |
| Comment by 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. |
| Comment by 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. |
| Comment by Robin Shen [ 07/Oct/15 12:02 AM ] |
| Please add that custom column just in case there are some unexpected changes in this regard. |
| Comment by 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. |