I am running Jenkins 1.595 with the TFS plugin 3.1.1 and TEE 12.0.2
I have been running jobs on Jenkins with Visual Studio Online for some time without issue, but I recently modified an existing job to point at a new branch and it stopped working. After much troubleshooting, I decided to stand up a brand new instance.
Right now in the new instance, I am getting the same error that I was getting in the old broken job.
An error occurred: TF14045: The identity grobocop is not a recognized identity.
(grobocop is an alternate credential associated to my MSDN account)
Looking at the command Jenkins is sending, I noticed that the workspace owner is specified after the workspace name which should not be a problem.
$ C:\TEE-CLC-12.0.2\tf.cmd workspace -new "Stage Author-MASTER;grobocop" -noprompt
-server:https://XXXXX.visualstudio.com/DefaultCollection ********
Running this same command in the command line produces the same error, but without the workspace owner, I get the prompts for username/password and the workspace is created.
Does anyone have any idea what is going on here?
I would recommend either dropping grobocop from the argument to new or you need to fully qualify it - grobocop#whatever.com. Grobocop by itself won't be accepted as the identity.
Related
I have a jenkins job that is failing due the error:
An error occurred: The path XXXX is already mapped in workspace YYYY;ZZZ\ServiceAccount.
The service account that is being referenced is from the domain that the TFS server was recently migrated from.
I have tried various fixes to remove this workspace mapping:
Run "tfs workspace -delete "{workspace name};ZZZ\ServiceAccount" -noprompt -server:tfs server -login:YYY"
This fails with the error message "ZZZ\ServiceAccount" is not a valid account. It is true that the account does not exist on the new domain.
Run "tf workspaces /remove:*" to remove all workspace caches. This completes.
Deleted the contents of "%AppData%\Local\Microsoft\Team Foundation\4.0\Cache".
Our TFS Server is running version 2013.
Tried using Team Foundation Sidekicks 2013. But this also fails to find any workspaces for "ZZZ\ServiceAccount".
I have tried on both the slave where the Jenkins job is run, and the Jenkins master.
Where might this workspace mapping be cached and how can I remove it now that the domain and user no longer exist?
Thanks in advance.
You can try the workaround provided by Jake Wallace in this case:
An easy workaround that has been used for several pipelines that have
run into this issue is to rename the pipeline. Not ideal but can add a
suffix or prefix to the pipeline until you run into the issue again.
In addition, after you clean all entries in %LOCALAPPDATA%\Microsoft\Team Foundation\4.0\Cache\*.*, did you restart the Jenkins agent and then rerun the build?
We have been using Sonarqube for about the last 2 months on our TFS 2017 server. Overall it has been very helpful, but a few weeks ago one of our builds started failing due to Sonarqube returning a 401 error (Unauthorised).
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Failed to request and parse 'http://sonarqube.local:9000/api/settings/values?component=MYPROJECTNAME%3Amaster': The remote server returned an error: (401) Unauthorized.
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Could not authorize while connecting to the SonarQube server. Check your credentials and try again.
The curious thing about this is that other builds from other projects are working absolutely fine, using the same API token. I've even created a new Sonarqube endpoint in the failing project, then again in a known good project - again using the same API key on both - only for the same thing to happen. One fails with the above error, the other is fine.
I thought this might have been a security/permission option within sonarqube itself, so I tried creating a completely new sonarqube project but again - one TFS project fails, while another succeeds when both are pointing to this new project.
I suspect this issue stems from the TFS project's security settings, but after comparing a good project with the bad project, nothing is jumping out at me as to what the cause may be - they seem to be set up the same. I enabled debugging on both a good build and the bad build and compared the outputs. As far as I can tell, the only real difference between the two is that the "Failing" build is picking up a sonar.password from somewhere whereas the good build is not:
Good:
2017-10-12T15:13:07.1067146Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]
2017-10-12T15:13:07.2785974Z ##[debug] arguments = /c ""Y:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe" begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.7" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master""
Bad:
2017-10-12T15:11:19.5733714Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]********
2017-10-12T15:11:19.5733714Z ##[debug] Path: Z:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe
2017-10-12T15:11:19.5733714Z ##[debug] Arguments: begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.3" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.password=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master"
(Note: Although the good/bad ran on different build agents in this instance, the agents are identical and I've confirmed that "good" projects work on all of our agents while the "bad" project fails with the same result on all agents).
However, I have no idea where it's getting this password from - there is no sonar.properties file in the repository. To be absolutely sure, I cloned the repository for the failing TFS project, pushed it into a repository in a working TFS project, replicated the build and it works.
I've checked the logs from Sonarqube itself and they are less than helpful
What could I have missed?
TFS 2017 is 15.117.26714.0
Sonarqube is 6.5.0.27846
Sonarqube task version is 3.0.2
EDIT: I have managed to get a temporary workaround for this by editing the build task to NOT insert sonar.password into the command line and this works. That does prove that the root issue is the task pulling this mystery password from "somewhere" but I'm still at a loss as to where it would be picking it up. I cannot find much information on what sets MSBuild.SonarQube.ServerPassword
Based on the (401) Unauthorized. Generally speaking you need to specify the authentication token in the SonarQube service endpoint in TFS: click! To obtain a user token in SonarQube follow these steps However, according to the troubleshooting you have done and one project worked, another not work, this should not related to your issue.
Just be sure the sonar.login and sonar.password properties in SonarQube.Analysis.xml are commented out, otherwise the token won't be used.
Also suggest you to compare the build definition of good build and bad build. Another way is creating a new build definition only with sonar qube related task for the bad project. To see if the authentication works, this will narrow down if the issue related to build definition.
For a specific project in my TFS 2015, a vNext build agent is unable to sync source code from the repository.
Only message I can see in log file is:
Starting: Get sources
Syncing repository: RDW (TFVC)
Workspace Name: ws_d565d474_34;Build\1b470f52-2a65-4b67-a68a-b8c32cebcad5
Done syncing repository RDW to version C283662 (workspace version -1)
Note that "workspace version -1". If I check the work folder on my build agent server is empty (not even created). Still the workspace on TFS side is created (checked with TF).
I checked the permissions assigned to the account I'm running the agent on and all seems fine.
I can't find anything in the log, nor on TFS, nor on agent computer.
It is happening only for one project. I tried with a different build server but the outcome is the same.
Does anyone have any tip on what should I check in order to try to solve this problem?
Thanks
I found the answer to my problem. I had the permission inheritance switched off on the folder in the source control under which all of my branches lied.
I do analyse the problem in a bit more details here http://blog.majcica.com/2015/12/24/tfs-2015-build-agent-failing-syncing-the-repository/
The build agent service account needs to be a member of the Build Service Accounts group.
I've browsed every post about TFS and Hudson I could find but nothing useful has popped up.
In Hudson when I attempt a build, the console output provides:
Started by user jlowder
[workspace] $ tf workspaces -format:brief -server:http://ashpteam01.hq.hanger.com:8080 **
TF30063: You are not authorized to access http://ashpteam01.hq.hanger.com:8080/.
FATAL: Executable returned an unexpected result code [100]
ERROR: null
[DEBUG] Skipping watched dependency update for build: NextGen Automation #25 due to result: FAILURE
Finished: FAILURE
If I manually run the tf command above from a command prompt, it works. I access TF from Visual Studio 2010 just fine.
I receive this error regardless if an attempt to access TFS comes from Hudson or Team City. My login to TFS is my domain user name and password, which I have checked and re-checked.
What am I missing here?
If you go to Control Panel > Network Passwords, are there any saved passwords there for your server? TFS will always try and authenticate using these first. If one is saved, and it is incorrect - you will get this error.
Also, what URL do you connect to in Visual Studio? Does it have a /tfs/ on the end?
It appears that the domain the server was running on would not send back to the domain I was requesting from. Moving hudson and tfs to same domain
Was able to connect to TFS 2008. After the upgrade to TFS 2010, I am unable to connect.
I reconfigured jenkins to use the new VS2010 tf.exe.
I reconfigured my job to point ot the new URL.
Verified my password is correct...
Within visual studio I can connect and use TFS 2010 without any problems.
However I am getting permissions problesm when trying to use Jenkins.
I have updated to version 1.20 of the TFS plugin and the problem still persists.
I have restarted the service before and after configuration changes...
Any ideas on what might be wrong? I changed the group/account in the log for safety.
Log is:
[workspace] $ "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf" workspaces -format:brief -server:http://sbn01p-tfs1001v:8080/tfs ********
TF50309: The following account does not have sufficient permissions to complete the operation: <group>\<my account>. The following permissions are needed to perform this operation: View collection-level information.
FATAL: Executable returned an unexpected result code [100]
ERROR: null
Team Foundation Server, beginning with TFS 2010, adds a new concept called Team Project Collections. Your Team Project Collection needs to be specified in the URI, for example:
http://sbn01p-tfs1001v:8080/tfs/DefaultCollection