<< Back to previous view |
[QB-3406] Configuration fails when there's an additional non-existent remote repository added to git repository
|
|
Status: | Resolved |
Project: | QuickBuild |
Component/s: | None |
Affects Version/s: | 7.0.28 |
Fix Version/s: | 9.0.12 |
Type: | Bug | Priority: | Major |
Reporter: | Sebastian Potasiak | Assigned To: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Remaining Estimate: | Unknown | Time Spent: | Unknown |
Original Estimate: | Unknown |
Description |
For a git repository defined in QuickBuild we have to add an extra remote repository, but when the address of the repository is wrong or the remote repository doesn't exist anymore, we get following error when trying to run the configuration (it's thrown before checking build condition):
2019-06-12 10:19:07 - Failed to run command: git fetch --all --tags -q Command return code: 1 Command error output: error: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it. error: Could not fetch external_repository error: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. In my opinion, since QuickBuild lets us define only one (origin) remote repository, it shouldn't try to fetch all remotes, but only the origin. Otherwise, we cannot do anything about this issue, as there's no way to handle errors thrown before checking build condition is triggered. |
Comments |
Comment by Robin Shen [ 12/Jun/19 11:45 PM ] |
As you mentioned, QB only adds the "origin" remote repository, then how is the extra remote added? Also have you tried to clean the configuration when this happens? |
Comment by Sebastian Potasiak [ 13/Jun/19 08:24 AM ] |
We add another remote repository with a command step. The working directory is set to the repository and we execute `git remote add ...` command there.
Cleaning it up indeed fixes the issue, but the URL to the remote repository is provided in a run dialog of the configuration by developers (multiple different repositories are added as a remote this way). There shouldn't be a need to clean the configuration at all. It's a bug, as `git fetch` command used internally in QB has a different scope (all remotes) than the defined repository (only one remote). In my opinion this either should be fixed, so we could compensate for the lack of functionalities with workarounds, or git repositories should support multiple remotes. |
Comment by Robin Shen [ 13/Jun/19 11:35 PM ] |
The "--all" option is added to fix issue |
Comment by Sebastian Potasiak [ 14/Jun/19 08:10 AM ] |
The `--all` parameter is not needed to fix issue .git/refs |-- heads | \-- master |-- remotes | \-- origin | |-- HEAD | |-- bugfix | |-- fix | \-- master \-- tags \-- 1.0.0 So, when you run `git fetch`, you get changes from the remote in the refs/remotes/origin directory. To have the changes on your local branches (refs/heads), you have to merge the changes from the remote branch to your local branch, e.g. `git merge origin/master master` OR use `git pull` that does both operations for you (fetch and merge). The `--all` parameter result is only that it fetches changes from all remotes if there is more than one remote added to local repository, and without adding the remotes like we do, using command step, the results of `git fetch` and `git fetch --all` are the same, as there's only one remote by default. Example of running git fetch on a repository locally (I've obfuscated potentially sensitive data) WITHOUT `--all` parameter: $ git fetch remote: Counting objects: 21360, done. remote: Compressing objects: 100% (7026/7026), done. remote: Total 21360 (delta 14314), reused 19603 (delta 13070) Receiving objects: 100% (21360/21360), 36.63 MiB | 1.94 MiB/s, done. Resolving deltas: 100% (14314/14314), completed with 1865 local objects. From ssh://url.of.our/repository c9b7cf781ff..786fa0992b2 master -> origin/master * [new branch] fix/fix-something -> origin/fix/fix-something * [new tag] 1.0.0 -> 1.0.0 Once the fetch is finished, you can calculate changes between all branches residing in the remote. See also: https://git-scm.com/docs/git-fetch And yes, we do need that because we have a huge project that requires interactions between multiple repositories that are used as remotes. Since there's no option to add more than one remote to the repository directly in the QuickBuild configuration, we have to "hack" it (to be honest, it's not a hack; we simply want to use git remotes like they are intended to be used and QuickBuild doesn't provide us this possibility, so we have to do it through command steps). In summary: 1. You do not need `--all` parameter to fix 2. It would be best if QuickBuild could handle multiple remotes natively, so we wouldn't have to manage them using command steps. |
Comment by Robin Shen [ 14/Jun/19 11:34 PM ] |
This is a very detailed explanation. Thanks a lot!
Following your suggestion, I verified that "git fetch" does able to get all branches/tags of the origin remote, and has made the changes in QB 9.0.12: https://build.pmease.com/build/4901 OTOH, we'd rather not to add additional options for multiple remotes to complicate the repository definition, as this seems like a rare case (at least not hearing about this requirement from other users till now) |
Comment by Sebastian Potasiak [ 17/Jun/19 06:32 AM ] |
Great! Thank you for solving this issue. As for multiple remotes for the repositories, I think it's fine for us, we already have a way around it in place. |