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.
Related
In my organization we have some Jenkins jobs building packages and pushing the packages to a private feed on Azure DevOps.
This has been running for years.
The build machine has Credential Manager Core running, enabling the job perform Git operations like tagging and updating submodules on same Azure DevOps orhanisation.
I suppose Credential Manager Core has also been used by Nuget Push.
Every time the Personal Access Token in %AppData%\Nuget\Nuget.Config expired, we created a new PAT for the AD user running the Jenkins service and updated NuGet.Config with:
nuget sources Update -Name <feedname> -UserName <user> -Password <PAT>
Since a few weeks now, the jobs started failing, and the Jenkins log shows:
C:\Users\<user>\.nuget\packages\nuget.commandline\5.8.0\tools\NuGet.exe push C:\Jenkins\workspace\<buildjob>\Deploy\MyPackage.1.0.17.nupkg -ApiKey [hidden] -Source \<feedname>
Pushing MyPackage.1.0.17.nupkg to 'https://pkgs.dev.azure.com/\<organization>/_packaging/\<some GUID>/nuget/v2/'...
PUT https://pkgs.dev.azure.com/<organization>/_packaging/\<some GUID>/nuget/v2/
MSBuild auto-detection: using msbuild version '17.3.1.41501' from 'C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\bin'.
Using credentials from config. UserName: ****
[CredentialProvider]Using the ADAL UI flow for uri https://pkgs.dev.azure.com/<organization>/_packaging/<feedname>/nuget/v3/index.json. User sign-in required in a pop-up authentication window.
[CredentialProvider]DeviceFlow: https://pkgs.dev.azure.com/<organization>/_packaging/<feedname>/nuget/v3/index.json
[CredentialProvider]ATTENTION: User interaction required.
**********************************************************************
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXXX to authenticate.
**********************************************************************
[CredentialProvider]Device flow authentication failed. User was presented with device flow, but didn't react within 90 seconds.
[CredentialProvider]Using the ADAL UI flow for uri https://pkgs.dev.azure.com/<organization>/_packaging/<feedname>/nuget/v3/index.json. User sign-in required in a pop-up authentication window.
Needless to say; user interaction during headless build is not very efficient.
I found an article describing Azure Artifacts Credential Provider and thought this might solve the problem.
According to section Other automated build scenarios it should be sufficient to declare an environment variable VSS_NUGET_EXTERNAL_FEED_ENDPOINTS with content like:
{"endpointCredentials": [{"endpoint":"https://pkgs.dev.azure.com/<organization>/_packaging/<feedname>/nuget/v3/index.json", "username":"optional", "password":"accesstoken"}]}
I replaced the "accesstoken" above with my own accesstoken, but still NuGet Push seems to depend on my %AppData%\Nuget\Nuget.Config.
The preferred solution would be to hold the Personal Access Token in a Jenkins Secret, and use that for Git clone and Git tag as well as for NuGet Restore and NuGet Push.
I find local config files and OS environment varables to be more problem prone, and would rather avoid them.
I am using Visual Studio 2019 with BitBucket Extensions installed.
For some reason I can no longer log into BitBucket from Visual Studio.
It's giving me an "Invalid Credentials" error.
I am using the same username (email address) and password that I use to log into the BitBucket website.
I tried uninstalling/reinstalling the BitBucket extension.
I tried changing my password.
For some reason I can no longer log into BitBucket to push/pull from my remote branch.
This has been working fine for 6 months. I am not sure what has changed.
Given that your login has been working fine for 6 months, I would say that creating a new App password on BitBucket will fix the Invalid Credentials, it probably expired.
Other approach would be to put your username without the domain, for example
arson#enterprises.org would be just arson.
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.
When I create a new Git repository in a TFS project area, there are several options to add some code.
I’ve tried the import a repository a couple of times now.
The first run gave me this error after an extended period of time. This would indicate a connection timeout based on my experience with other tools and process.
We checked the logs in the EventViewer on the application server side but couldnt find anything. We suspect an SSL/cert issue between BitBucket and TFS 2018. This is also hosted in-house.
Please double check whether the URL is correct. And please notice import service relies on basic authentication to communicate with the source repository. If the username / password you are using are not basic auth then authentication will fail and import will fail. One way to check if the username / password you are using are basic auth or not is to try using Git to clone your repository using the below format:
git clone https://<<username>>:<<password>>#<<remaining clone Url>>
Please refer to the following link for more details:
https://learn.microsoft.com/en-us/vsts/git/import-git-repository?view=vsts#frequently-asked-questions
I'm setting up TFS 2015 for my team to try out, and I'm having trouble getting it off the ground. It sounded straightforward, but things don't work and I can't find any diagnostics, and tutorials don't match what I'm seeing. Some highlights:
When I go to download a Build Agent from the server, I don't get a PowerShell file (ConfigureAgent.ps1), I get ConfigureAgent.cmd.
The images and description of setting up the build controller show me a nice picture of the TFS Admin Console with a Build Controller and Build Agent and their statuses underneath 'Build' (see Team Foundation Server 2015 Builds will not start or https://msdn.microsoft.com/en-us/library/ms181712.aspx.) On my system, I see this display under XAML Build Config (the old way,) but the Build item in the console doesn't have anything like that. It has a link to download an agent, but installing an agent doesn't change this.
Installing the agent appears to work. I get a service that's running, and the web portal agrees that I have an agent in the default queue and pool.
But, queuing a build just sits there. I've found the _diag folder for the agent, which has logs with a bunch of "Message received, no message retrieved" lines. I can't find anywhere else to check if the server knows about this build.
The service account is Network Service, and I've tried putting it in every TFS group mentioned online regarding permissions.
My setup is TFS and VS 2015 installed on our build machine, with it also hosting the build agent. I'm on port 8079, because port 8080 is taken. It's got to be something silly I missed, because everything looks like it's working. Has anyone gotten this beast off the ground without coming from a pre-existing install?
The configureagent.cmd is the correct file (it does pretty much what he ps script did)
Make sure the account that the agent is run under is in the "Agent Pool Service Account" role. It is better to use a domain/machine account not a local service account.
Make sure the queue is provisioned in the collection ( https://your-tfs-server:8080/tfs/your-collection/_admin/_AgentQueue ). If not - select "New queue.." and select the existing queue.
Make sure that when setting up the build through web access, the demands (on the general tab) is met by the capabilities of the agent.
If all this is in place, I have found that it facilitates testing by running the agent in interactive mode (not as a service). This gives you a bit better insight into what is happening. When it is working you can configure it as a service again.
Use an actual service account, not NETWORK SERVICE, and make sure that service account is a member of the Build Service Accounts group in your Team Project.
For me the issue was that the IIS's Team Foundation Server site setting's Authentication, "Windows Authentication" had to be enabled.
I was using a windows user as the log in credentials for the Build Agent running as a service.
Remember this new build system uses all http now.
It does not talk to any tfs build controller.