We have a Git repo on TFS and I am trying to create a pipeline using azure pipelines to connect to the TFS repos.
I get the following error:
fatal: unable to access 'http://tfs.****************': Could not resolve host: tfs.******
##[error]Git fetch failed with exit code: 128
I would suggest you first use "git clone" command line to clone remote repo.
Kindly check when you run it manually from the build agent, it work for that repo or not.
This will narrow down if the issue related to your environment or pipeline.
If you are able to use git command to connect and clone that repo.
This means there is something wrong with your build service
account. You should make sure build service account has access to that
repo. You could also directly change the service account to the one
you used to run git command.
If you are not able to do it. Then this may related to network
environment. Make sure your build agent are able to access TFS
on-premise server. Temporarily turn off firewall and any proxy. Also
try to directly use browser to login TFS web portal.
It seems that it is a self-deployment of TFS server then you need to make sure that the Server can be reached from Azure DevOps.
Based on URL in your post, I assume server is not reachable from public internet. So TFS server should be either on-prem or on a VM in Azure. So reach out to your infrastructure team to see where the server is, and how the connection could be established from build agent being used by Azure DevOps to the TFS server.
Related
Azure DevOps Server 2020 with self hosted agents on a different server
I have a build, which is creating an artifact in Azure Artifacts, then a release pipeline is triggered which should download this artifact and do something with it. Previously, the output of a build was on a file share and it work as expected. When I switched to Azure Artifacts - the download artifact task (which is added automatically by Azure DevOps) fails with following:
All other build tasks work on this server without a problem, and also this release pipeline works as expected on other servers. How I can start to troubleshoot this issue as I don't see any meaningful error message?
According to your screenshot, I could reproduce the similar issue in Azure Devops Server.
But in the task, I could see the error message:
Failed in getBuildApi with error: Error: self signed certificate.
If you have the same issue, you could try the following methods:
1.You could re-config the agent with the self signed certificate.
.\config.cmd --sslcacert ca.pem xxxx
Here is a ticket about the detailed steps, you could refer to it.
2.You could check if you have set the firewall. Firewalls could block the download of artifacts
3.You could set the system environment :NODE_TLS_REJECT_UNAUTHORIZED=0 and restart the agent services.
We had similar problem with self-hosted agents but there was a minor difference - our agents were deployed in vnet.
If that's the case make sure that in vnet's subnet you have enabled Microsoft.Storage service endpoint.
Hope this will save someone tons of time.
I am trying since awhile to setup an Azure Pipeline to access our internal TFS 2018 server.
I created an "Other Git" Service Connection named: TFS_PRJ, I used this intranet URL: https://tfs.mycie.com/DefaultCollection/myProject/.
For the authentication, I tried, my Windows domain account credentials as well as a PAT Token created in TFS with all access rights.
When I created the pipeline, I specified my self-hosted agent located on the same intranet and the master branch. Does this branch have an impact when accessing TFS? I can see in the logs: "Starting: Checkout TFS_PRJ#master to s". I don't see branches in TFS, should I create something in TFS to make it work?
When running the pipeline, I first have a timeout
Then it runs and after 6-7 minutes, logs shows this error: fatal: unable to access 'https://tfs.myCie.com/DefaultCollection/myProject/': OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to tfs.myCie.com:443
I understood that to access this server, the agent should not use the proxy that is currently used in pipelines accessing GitHub. This bypass is usually done by using a proxy.pac file but I don't see how to use this file in agent configuration. To enable the proxy bypass with agent files, the .proxy file contains: http://abs-proxy.myCie.com:443 and the .proxybypass file contains: myCie.com
To test that the TFS server is accessible, I logged onto the agent server as the service account and in the IE Internet options, I added *.myCie.com to the trusted sites and then I was able to access https://tfs.mycie.com/DefaultCollection/myProject/. I am also able to ping the tfs.mycie.com server
So, I have several questions:
The branch part, is it normal to use the master branch while there is no branch in TFS or does it need something more?
When I run the pipeline, it gives a timeout as it can't connect to TFS but what account and what proxy does it try to use at this point? The one defined in the service connection?
About the SSL_ERROR_SYSCALL error, is it my syntax of the .proxybypass file that is wrong? "myCie.com", do you see anything thing else that could be done ?
Can there be some settings or access rights on the TFS server that I need to have or set ?
Update 1:
Thank you for this.
I created a YAML file in a Azure Repos with this content:
trigger:
- none
pool:
name: 'myAgent'
steps:
- checkout: none
- task: CmdLine#2
inputs:
script: 'git clone -b master https://tfs.myCie.com/DefaultCollection/myProject'
Which returned:
Cloning into 'myProject'...
fatal: could not read Username for 'https://tfs.myCie.com': terminal prompts disabled
I should probably try with the PATToken in the URL...
On the agent, I added the Git folder of the agent to the path and ran:
git clone https://anything:PATTokenToMyLogin#tfs.myCie.com/defaultcollection/myProject
Which returned:
Cloning into 'myProject'...
fatal: Authentication failed for 'https://tfs.myCie.com/defaultcollection/myProject/'
Then I tried to clone it from the Team Explorer in VS2019.
I have found two lists of projects, tfs.myCie.com and "local Git repositories", I couldn't clone projects from tfs.myCie.com so I tried to clone in the local Git but it didn't worked, not sure it was the thing to do either...
I took this screenshot, could it be my TFS project that is not suited for this ?
If you do not have other branch in TFS, it is normal to use the master branch, also we can specify branch name in the Get sources tab, please check the pic below.
You could check the service connection in the project settings->Service connections. It accesses the TFS repo via service account, such as below.
According to the error message OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to : It seems to be an issue in your network settings, maybe a proxy or a firewall blocking access to the remote repository.
You should check if your TFS server is behind the firewall or a proxy. If so, please turn it off and try again. Please also try running the clone command in a local machine directly to clone the affected repository to check if that works. If the server is behind a proxy, please try to set git configs for proxy something like this : git config --global http.proxy myproxy.com:8080
You need configure the service account permission in the TFS Version Control.
Update1
Please check the sample, I disable the checkout step and add cmd to clone TFS 2018 repo, then publish it to Artifacts to check the content.
Note: The repo will save in the self-hosted agent folder, we could add task Power shell at the end and call script to delete the repo folder.
trigger:
- none
pool:
name: Default
steps:
- checkout: none
- task: CmdLine#2
inputs:
script: 'git clone -b {branch name} {TFS repo URL}'
- task: CopyFiles#2
inputs:
SourceFolder: '$(Agent.BuildDirectory)'
Contents: '**'
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Result:
Update2
It’s mainly caused by the credentials have been remembered by Credential Manager. You should remove the credentials for https://tfs.myCie.com which have been stored in Credential Manager.
you can open Credential Manager -> Windows Credentials -> under Generic Credentials -> remove the credentials like git:https://tfs.myCie.com
In addition, please also delete the Visual Studio cache.
Note: You could also try to clone repo on a new machine.
I have a Git repository on the Azure Dev-ops server and use Jenkins for continuous integration build.
I want to know that how a specific branch like master Jenkins can automatically run the build and then notify the user via a shell log that the build was successful or not?
Microsoft seems to have the thing pretty well documented, Create a service hook for Azure DevOps Services and TFS with Jenkins
Set up the Jenkins job, set up the TFS / Azure DrevOps ServiceHook, off to the races.
We have it working fine for Jenkins 2.x and AzureDevOps on-prem. Best to use service accounts with limited necessary permissions on both sides.
I'm little confused about Jenkins and was hoping someone could clarify some matter for me.
After reading up on Jenkins, both from official docs and various tutorials I get this:
If I wanna set up auto deplyoment or anything Jenkins related, I could just install docker jenkins image, launch it and access it via localhost. That is clear to me.
Then, I just put Jenkinsfile into my repository, so that it knows what and how to build my repo and stuff.
The questions that I have are:
It seems to me that Jenkins needs to be running all the time, so that it can watch for all the repo changes and trigger code building, testing and deploying. If that is the case, I'd have to install Jenkins on my droplet server. But how do I then access my dashboard, if all I have is ssh access?
If Jenkins doesn't need to be up and running 24/7, then how does it watch for any changes?
I'll try to deploy my backend and front apps on docker-compose file on my server. I'm not sure where does Jenkins integrates in all that.
How Jenkins can watch for all the repository changes and trigger code building, testing and deploying?
If Jenkins doesn't need to be up and running 24/7, then how does it watch for any changes?
Jenkins and other automation servers offer two options to watch source code changes:
Poll SCM: Download and compare source code at predefined intervals.This is simple but, hardware consumption is elevated and is a little outdated
Webhooks: Optimal functionality offered by github, bitbucket, gitlab, etc. in which Github, for example, at any git event, makes an http request to your automation server, sending all the information like branch name, commit author, etc). Here more info about webhooks and jenkins.
If you don't want a 24/7 dedicated server, you can use:
Some serverless platform or just a simple application able to receive http posts + webhook strategy. For instance, Github will perform a post requet to your app/servlerless and at this point, just execute your build, test or any other commands to deploy your application.
https://buddy.works/. It is like a mini-jenkins.
If I'd have to install Jenkins on my droplet server. But how do I then access my dashboard, if all I have is ssh access?
Yes. Jenkins is an automation server, so it needs its own dedicated server.
You can install jenkins manually or use docker in your droplet. Configure 8080 port for your jenkins. If everyting is ok, just access to your droplet public ip offered by digitalocean, like: http://197.154.458.456:8080. This url must load the Jenkins dashboard.
There are lots of question on here about Permission denied (publickey) errors when using the Jenkins git plugin.
Can someone explain the authentication flow this plugin uses to check out a repository? I can't find a good description on the plugin page.
I want to just SSH into the build slave, checkout the repository there, then run my job, but clearly that is not how it works.
I guess I could add my credentials to the jenkins master, but I dont want any code there. I want it on my build slave.
Issue has nothing to do with git really. As their documentation states, it relies on git runtime which in its turn relies on system environment when it comes to secure connections. Ssh requires client to have valid key to connect and fails to that message if client does not provide one. Without any additional actions, key is not injected into environment, so client could not provide any valid key.
What you actually can use is ssh agent plugin. That allows to add key to ssh-agent on slave that will be catched up by git.