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

Key: QB-3460
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Martin Falkner
Votes: 0
Watchers: 0

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

Labeling not not possible anymore since update to 9.0.23

Created: 21/Oct/19 01:57 PM   Updated: 11/Nov/19 07:43 AM
Component/s: None
Affects Version/s: 9.0.23
Fix Version/s: 9.0.26

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

 Description  « Hide
After update to 9.0.23 the step 'Label' fails.
Earlier 'Checkout' step on the same repository works fine.
Step Type: Label
Label Name: build/20191021_1259_S2BTSER.000D9311

Error output:
Failed to run command: "C:\Program Files\Git\bin\git.exe" push -f -q ssh://xxxxxxx.com:29418/TDMOB/Platform/Fusion/HAL.git build/20191021_1259_S2BTSER.000D9311:build/20191021_1259_S2BTSER.000D9311
Command return code: 128
Command error output: Password authentication
Password authentication
Password authentication
Permission denied, please try again.
Permission denied, please try again.
xxxxxxx: Permission denied (password,keyboard-interactive,publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

 All   Comments   Work Log   Change History      Sort Order:
Steve Luo [22/Oct/19 03:01 AM]
Hi, I have tested with ssh url like you and without any problem. Please check the command from your command line to see whether it can work.

And please also notice that your ssh key should be passwordless. I'm also curious why "Checkout" step can work. In my opinion, it can work only if the push url is not same as the pull url.

Martin Falkner [22/Oct/19 04:05 AM]
Hi Steve,
I'm also clueless as this node/build worked fine for years. There were no changes, except the update to 9.0.23.
There is only one repository defined in this node, therefore, the checkout and label are done on the same repository.
The SSH key is passwordless.
If I create a tag on the command line and push with 'git push --tag' it works perfect.
However, if I copy the command from the error message to the command line it will not do it.
I do not know what commands are used to do those steps, but I've attached the session log of my test.
Do you have any hint what I could test in addition?

Martin Falkner [22/Oct/19 04:07 AM]
BTW: Is there any way to revert to older version?
If yes, I could verify whether it is really related to this update or not.

Steve Luo [22/Oct/19 04:44 AM]
Yes, you can revert it back, just copy the old git plugin to replace the new one and restart the server.

Steve Luo [22/Oct/19 04:49 AM]
You have added user part in your url, while QuickBuild doesn't have. So is it possible that is the problem? You can add user part to the url in quickbuld to see if it can help.

Steve Luo [22/Oct/19 04:51 AM]
Or, you can add user to ssh config like:

Host mygit.server.com
    User xxxx
    IdentityFile xxxxxxx

By the way, I deleted the GitSession.txt file you uploaded for privacy issue.

Martin Falkner [22/Oct/19 05:43 PM]
Hi Steve, I've reverted all the GIT plugins back to version 9.0.17, and bow it works again.
Therefore I assume it has to do with the update to 9.0.23 and not and other setting.

Martin Falkner [22/Oct/19 05:47 PM]
Working versions:

Not working versions:

Steve Luo [23/Oct/19 11:07 AM]
So strange. I still can not reproduce the issue.

Are you using git server like github, bitbucket or gitlab? Or just file system?

Can this issue be reproduced in your other configuration/repo or just for this configuration/repo?

Martin Falkner [23/Oct/19 11:40 AM]
It's a Gitblit server.
It happened to all repositories on this server at the same time (after the update).
Actually, while you are mentioning this, I've got one repository on GitHub, there it did not happen.

Steve Luo [24/Oct/19 07:39 AM]
I have installed a Gitblit server and still can't reproduce the issue. Is there any clue in Gitblit server side? How about doing some test with a new ssh key to see if the issue persists?

I also checked the changes since 9.0.17, and still no findings. Actually, we just invoke the commands to checkout and label the repo, and if you turn the configuration log level to debug, you can see all the commands we invoked.

Martin Falkner [25/Oct/19 03:53 PM]
Steve, this was a great suggestion, I think I see the problem now.
Here the two different commands:
Version 17: git.exe push -f ssh://gituser@url.com:12345/x/IFMS.git build/LABEL:build/LABEL
Version 23: git.exe push -f ssh://url.com:12345/x/IFMS.git build/LABEL:build/LABEL

The only difference is the user name, and this makes sense now.
As the QuickBuild Server service cannot run with the same user name as the one used for GIT, the username has always to be added to the command, or, the URL has to be omitted, then the URL and username will come out of the GIT configuration.
For this reason I've defined the GIT user name together with the repository.
"User Name: Optionally specify the user who has permission to access the above url."

Any reason why you removed the username for this command in the new version?

Steve Luo [27/Oct/19 10:44 AM]
Hi Martin, thanks a lot for the information. Yes, you are right, username field is not added to the url when ssh protocol is used, see below issue:


But, you can add user part directly in URL, for example, you can define the fetch url like:


in this way, the ssh should work as before.

Martin Falkner [28/Oct/19 11:00 AM]
I'm confused now:
If I add it to the URL in general, will I not get problems with other commands?
Isn't this wat the files 'User Name' in the repository setup is used for? If not, what is is used for then?
Or, should I just add a push URL with the user name?

Steve Luo [28/Oct/19 02:00 PM]
Yes, it's really confusing here. Most of the git host like GitHub, GitLab use below url for SSH connection:

to avoid the conflict, we decided not to add the 'User Name' field to the url in this SSH case (as you see, the username usually already existed). But it seems this is more confusing for user. So we'll still add 'User Name' in later version.

So, you can just add the username to the URL directly or wait for our next patch release.

Martin Falkner [11/Nov/19 07:43 AM]
Thanks for the update 26, it's working again.