We recently migrated from an on-premise TFS server to Azure DevOps. Our team uses TFVC for source control, and I'm getting the following exception when Jenkins polls for new check-ins:
FATAL: This server requires federated authentication but no mechanism was available to handle it.
com.microsoft.tfs.core.exceptions.TFSFederatedAuthException: This server requires federated authentication but no mechanism was available to handle it.
Given the exception class name is TFSFederatedAuthException I suspect Azure is expecting some sort of OAuth integration, but Jenkins doesn't appear to support that for TFVC.
All I did was change the Collection URL for that Jenkins build to https://dev.azure.com/MyCompany. The Project path remains the same, and I verified this, because I was able to re-map all of my TFVC branches in Visual Studio by just pointing to the different collection URL and keeping the same project path. A screenshot of the Jenkins source control config is below:
This Jenkins server is internal with no public facing IP address or host name.
How can I allow Jenkins to poll a TFVC repository hosted in Azure DevOps in order to trigger a CI build in Jenkins?
Why not use Azure pipelines? That's a much bigger migration effort at the moment, and I'm just trying to solve a short term problem.
Using Azure pipelines is my long term goal, but I need to figure out how our automated tests can use an Oracle database first, because all data is deleted before each test is executed using Selenium.
Azure DevOps uses OAuth to communicate by default, putting in your username and password won't work because of that. Instead, the trick is to generate a Personal Access Token (I suspect the Code|Read+Write scope should do it) and pass that in.
For the username pass in ., for the password your generated personal access token. Give the token a nice name so you know which one is about to expire once you get the email notification.
Related
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 am using the Azure Devops CLI on one of my pipelines. In order to use the CLI I need first login (authenticate). Unlike using the REST API, I can't use the OAuth token that is available to me.
So here's my understanding of my options:
I can do an "az login" using a PAT that I map to this environment variable:
AZURE_DEVOPS_EXT_PAT
THIS IS THE WAY I'm doing it now.
Apparently you can use a Service Principal. I like this the most because I should theoretically be able to have this principal apply to everyone on my team. Is that correct?
Use "az login" with a user/password. This is least desirable way to doing it because it involves passing around credentials. Too messy.
Although my pipeline has the OAuth token expost (System.AccessToken), it cannot be use by the CLI. For example is I try to assign the value of the OAuth token to the AZURE_DEVOPS_EXT_PAT it fails (AZURE_DEVOPS_EXT_PAT=$System.AccessToken).
Questions:
Is it possible to use the OAuth token to log in to the CLI?
Is the Service Principal the best way to go?
Additional Info:
I do not have subscriptions only a tenant-id, we're not creating any Azure resources, we're an AWS shop that happens to be using ADO only for CICD.
Use az devops login instead of az login
From your pipeline use:
- script: echo $(AccessToken) | az devops login
env:
AccessToken: $(System.AccessToken)
Few interesting notes:
Secrets (like System.AccessToken) are available to scripts unless you pass them in explicitly as environment variables
the System.AccessToken variable is the default access token of the build agent
there is a project-specific build agent and a project-collection build agent. The one you use is actually controlled by the 'limit access to current project scope' flag in the Pipeline settings for the project.
you may need to elevate permissions for the build agent if you're trying to manipulate objects. For example, you could grant the Create Tag permission on a repository if you wanted the build agent to update the repository.
you can also create your own PAT token with permissions that you specify.
I migrated all the Jenkins related file from one server to another. Everything is working fine. The only problem is I am not able to see all the users and project role which were set in previous Jenkins server. I am using Role-based Authorization strategy. Any way of getting all the previous users in the new Jenkins?
I had same task to migrate jenkins from one server to another and the solution I used was rsync which did the job.
If you have *nix servers, I would suggest you to go via rsync also
I have instances of Jenkins and GitLab which are successfully connected. Part of setting up the GitLab plug-in involves providing an API token. I believe this is used by the plug-in to get details of the commit which is triggering a job.
I need to run a daily Jenkins job which collects some statistics using the API and then (using R) generates a report. So this is not triggered by an event in GitLab.
To complicate issues a little further, the R code will run inside a container (to avoid hving to install R and all the packages on every Jenkins slave),
It does not appear that the plug-in makes the token available to be used in jobs ... and I can see a sane reason for that.
Is it possible to access the API token from the plug-in?
There is a plugin which supports credential injecting (https://wiki.jenkins.io/display/JENKINS/Credentials+Binding+Plugin) to the builds which could be used later as an environment variable. Gitlab api token could be also selected.
We are using Hudson as a CI tool. At present we are needed to use Jenkins, to deploy the build to Stage, Prod environment. What is the best aproach we should follow.
I know about promote buld plugin, but the issue is authentication. I want whevener we need to promote a build to deploy to Stage or Prod, it should ask for netqwork credential first. And then the promote job should execute the Batch command using the creadential supplied. At present, the promote plugin, runs using the credentials which the Tomcat server is configured to run.
Same issue with Build Pipeline plugin.
I want only dev or even hudson admin also should not be able to execute the promote build unless credential supplied. (We have windows 2008 r2 OS)
Can you please help me in resolving the issue. so that basically whenever a user click on Promote build to QA\Stage\Prod the plugin should ask for credential or should use the logged on users credential and execute the batch script using the logged users credential only and not by using the credentials of the account with which the tomcat server is configured.
Can you please help me?
Please suggests us the best aproach for making automated build on prod\stage.
For deployment I normally use SSH, Private/Public keys takes care of the authentication problems normally associated with running commands on other servers.
SSH is normally associated with unix based systems, but it does support windows.
Finally, I would recommend considering decoupling your build system (jenkins) from the system performing the deployment by using an intermediate repository. See the following answer for more details:
Jenkins : how to check out artifact from Nexus and Deploy on Tomcat-