How to clear TFS Cache in a linux machine - jenkins

After removal of existing account all the workspaes for old account was deleted in my linux Jenkins server. But when changed configuration to new Account credentials. I am finding old workspaces could not be overrided with new account details. where on server side we could not find that workspace details.
Is there a way we can clear linux client cache?

According to my understand, seems you want to migrate all workspaces from your old user to another user. This can be accomplished by command line tool tf.exe
tf workspaces /updateUserName:OldUserName /collection:collectionurl
This should be done with your new account, and will assign all workspaces from old account to current account.
/updateUserName
Updates security identification information on the Team Foundation
server for a user whose network user name has been changed. If you
specify this option, you must also specify a team project collection
by using the /collection option.
More details please refer Workspaces Command For Linux machine, you could use Team Explorer Everywhere (TEE) an Eclipse plug-in and a command-line client to run the command.
Another way is creating the server workspace on Windows, then use the /template option on Linux to setup the same configuration.

Related

Unable to validate collection

I am trying to set up TFS for vscode. I am getting the error, unable to validate the collection assuming 'default collection', when signing in. Any recommendations oh how to resolve this issue.
Firstly make sure you have correctly set the TFVC support.
Below is a short list of steps to get up-and-running with TFVC support:
Install the Team Services extension for Visual Studio Code.
Team Foundation Server requires your domain credentials.
Ensure you have a TF command line client installed (either TF.exe or
the TEE CLC).
Set the tfvc.location VS Code setting to the full path of your TF
command line client.
Open a folder containing a Local TFVC Workspace and sign in when
prompted.
Set the SCM Provider to TFVC.
For more detail tutorial you could also take a look at my reply in this question How can I connect to on-premises TFS using visual studio code?
Back on the error message, it may related to the workspace. Check if you have correctly mapped the workspace. Just try to remap the existing workspace or create a new workspace and map sources to a new local folder, then check that again.
Also just try to specify the collection and team project name in the user settings like this:
{
"tfvc.location": "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\tf.exe",
"team.remoteUrl": "http://server:8080/tfs/collection",
"team.teamProject": "TeamProjectName",
"tfvc.restrictWorkspace": true,
"window.zoomLevel": 2
}

TFS(On-Prem) Build Agent(On-Prem) Not Finding Visual Studio 2017 Capability While Running As Service

Microsoft Visual Studio Team Foundation Server - Version 16.131.28106.2
Agent.OS Windows_NT
Agent.OSVersion 6.3.9600
Agent.Version 2.136.1
My TFS build agent is not identifying Visual Studio 2017(Enterprise) as a capability while running as a service(under a service account on my primary domain). That same agent does identify Visual Studio 2015 as a capability while running as a service under the same account as above.
I've updated the agent, removed and reconfigured the build agent in question, restarted the agent-service, and restarted the OS. I did notice that when this agent is first configured, the capability is briefly identified while the agent runs under the individual running the configure script, but when the agent switches over to running under the service account, the VS2017 capabilities disappear.
After noticing this, I gave the service account in question read and execute privileges on the root Windows install dir, 'Program Files (x86), and all directories and files associated with the VS2017 install, but this didn't help.
If I run a different build agent interactively(same version as listed above), VS2017 is identified as a capability, so I'm assuming there is something I need to do in regards to the service account I'm attempting to use.
For good measure, within the Visual Studio build task, I tried using the 'latest' option and the 'Visual Studio 2017' options. I also tried adding '/p:VisualStudioVersion=15.0' to the MSBuild args for this task.
Update: I also tried explicitly specifying the capabilities directly in the 'User-Defined' section, and I tried adding the capabilities through the use of environment variables on the agent host.
Have you ensured that the service account user is added as the role service account on the pool the agent is running on?
Also ensure that the service account is able to do the following in these Local Security Policies: "logon as a service", "act as part of the operating system", "Manage auditing and security log"
I can't say that this will be able to solve your problem, but I just know that these are necessary in the setups I handle.
You could also for quick and easy test add you service account as an administrator on the machine and test if it finds VS 2017 then. If it does, then you know you need to set some specific groups and permissions.

How to Setup VSTS to work with VS Code over Unix (TEE-CLC)

I had been trying to setup my VS Code and plugin VS Team Services 1.22.0 (need to setup TEE-CLC). But I have been hitting the same wall.
Checks:
-Java Installl
-Download TEE-CLC
-Installed VS Team Services Plug In
-Setup "tfvc.location"
-Created a local folder in my documents
Over TEE-CLC 14.123.1 I had accepted the Eula(Easy process), created a workspace using the TEE in VSTS(with success):
tf workspace -new MyWorkspace -collection:https://dummy.visualstudio.com/
Workspace 'MyWorkspace' created.
Then the part where I get stuck is mapping my local folder.
I had try official setup process(plugging over VS Code)
Used this How do you create new windows workspace with TFS command line client that is running on unix
Follow videos to setup TEE-CLC without success.
I know I'm missing something but don't find yet what could be.
If you use on-premises TFS, you must be running Team Foundation Server 2015 Update 2 or later.
After installing Team Services extension and TEE CLC (see how to set it up by viewing this video), you also need the following steps:
Set the tfvc.location VS Code setting to the full path of your TF command line client.
Open a folder containing a Local TFVC Workspace and sign in when prompted. Refer to this site.
Set the SCM Provider to TFVC. Refer to this site for more information.
If you are unable to access the existing local workspace using TEE
CLC, try the steps below:
using the CLC, run the tf workspaces -collection:<collection-url> command, to help the CLC be aware of the workspaces in the specified
collection.
Run the tf workfold command from the local folder being accessed from Visual Studio Code.
Running both commands should make the TEE CLC aware of the workspace
and as well as verify that access to it is possible.
I'd like to suggest go through the website below:
https://github.com/Microsoft/vsts-vscode/blob/master/TFVC_README.md

How to get fix "You are not authorized to access" accessing VS Team Services

I can open internet explorer and login just fine.
Credentials are saved in the credential manager.
Trying to access any tf.exe command results in a TF30063 error.
I do not have VS installed on this machine.
Any suggestions on what to try?
UPDATE:
Here are the step I've taken to get this error.
Login to VS Team Services via IE
At the command prompt:
C:\>tf.exe status /collection:https://xxxxx.visualstudio.com/DefaultCollection
C:\>tf.exe workspaces /collection:https://xxxxx.visualstudio.com
C:\>tf.exe workspace /new /collection:https://xxxxx.visualstudio.com
I've also tried a few others and everyone of them return with the same unauthorized error.
These commands all work on another server that's connected to the same tfs repo with the same credentials, which leads me to believe it's something in IE and/or internet security options.
Taking add files and folders to version control as example, you can specify the user account /login:username,[password] in the command:
tf add itemspec [/lock:(none|checkin|checkout)] [/encoding:filetype]
[/noprompt] [/recursive] [/noignore] [/login:username,[password]]
More commands, see: https://www.visualstudio.com/en-us/docs/tfvc/use-team-foundation-version-control-commands
To use tf.exe command, you need either Visual Studio or Team Explorer is installed. More details please refer Command-line tools for TFS

Setup Jenkins on VSO with TFS

Has anyone successfully set up VSO & Jenkins & TFS?
Server URL: https://<myproject>.visualstudio.com/DefaultCollection
Login name and user password (using alternative credentials)
What domain name did you use? <domain>\username
If I run the tf command in Command Prompt, it succeeds, but Jenkins shows the same command as failing. I'm lost as to how to debug this. I also tried setting cached credentials for TFS, and not caching them. It seems as though Jenkins does not have cached credentials, but my command prompt does? Why would my system have stored credentials for me, but not Jenkins?
Error from Jenkins: TF30063: You are not authorized to access https://windwardstudios.visualstudio.com/DefaultCollection
With the release of version 4.0.0 of the Jenkins Team Foundation Server plugin, Team Foundation Version Control (TFVC) from Visual Studio Online (VSO) is now officially supported and both Personal Access Tokens (PAT) & alternate credentials can be used.
See the section User name and password in the wiki page.
This is an answer, but may not be what you want to hear. This used to work for us about a year ago. It required someone to stay logged into VisualStudio.com with his MSDN credentials on the build server. Then we simply didn't use credentials in the Jenkins TFS plug-in. Then one day, that simply stopped working. We tried alternative credentials, as #MrHinsh suggested, but never got it to work. Eventually we gave up and switched all of our TFS repositories to git (but still hosted on VisualStudio.com). That does work with the alternate credentials, and we have been very pleased since.
You need to configure Jenkins yo use the alternate credentials. It will not work with any other configuration and the credentials are never stored. Every command that you pass must include the same creds.

Resources