| << Back to previous view |
|
[QB-2151] Continue with the build even if changes can not be fetched in case of git branch rebase
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 5.1.32 |
| Fix Version/s: | 6.0.0 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Robin Shen | Assigned To: | Robin Shen |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
It's nice that QB tries to decide what new revisions where introduced, but it breaks when a branch is rebased in Git. We regularly do this to clean up history and absorb conflicting changes on master, and when we do, the build fails with something like:
06:57:52,837 INFO - Checking out revision 'e64a68f2a6eca3601c2c5e7c2ef4f13c40a7f6b9' of repository 'git-repo'... 06:57:52,839 INFO - Repository setting changed, deleting working directory [/opt/buildagent/workspace/root/castanet/castanet/dev/play-with-rpms] 06:58:01,841 INFO - Getting changes of 'git-repo' since build '4.4.0.dev1753'... 06:58:01,846 ERROR - fatal: bad object 73efa2e587cac0fd4aaf06a16b0e1f225bedd238 06:58:01,848 INFO - Executing post-execute action... 06:58:01,848 ERROR - Step 'master>master-full>checkout' is failed: Failed to run command: git log -1 --date=raw --pretty=format:%cd 73efa2e587cac0fd4aaf06a16b0e1f225bedd238 Command return code: 128 Command error output: fatal: bad object 73efa2e587cac0fd4aaf06a16b0e1f225bedd238 Then we have to reach in and kick it again. :-( It'd be nice if QB could be better behaved here. Perhaps we could setup a default branch it could compare against (say master), and it could use that as a fallback? I'd be happy with it not telling me anything about the included commits as long as it continued the build. |