We recently switched our Azure DevOps organization from the free Hosted Agent offering to two paid hosted agents. When the second hosted agent was added, it was automatically named "Azure Pipelines 2" which is a fine enough name. The issue is that the original agent seems to be named "Hosted Agent" and I can't for the life of me find a way to rename it. It would be great if it could just be renamed to "Azure Pipelines 1". Is it possible to rename a hosted agent? If so, how does one do this as I have looked in Organization Settings at the Agent Pools option and do not see any way to do this.
Rename Azure DevOps hosted Agent
For this issue , I am afraid this is currently not supported in Azure Devops. Hosted agent name cannot be modified.
Currently only private agent name can be renamed, run config.cmd remove first, that will take care of remove the windows service and also remove the agent from your azure devops , then run config.cmd again to re-config in order to change the agent name, the agent name is a primary key in the backend.
So I post a feature request here in DC forum for you . You could vote that suggestion ticket and share your comment there.The product team would provide the updates if they view it. Anyone interested in this can vote for it and track it.
Related
is it possible to change the agent.name? without to delete the agent and reinstall?
linux system
picture
I try to vim the config.sh and I didn't find that variable
I am afraid that there is no such method can directly change the agent name without re-installing the self-hosted agent.
The agent name is a primary key in the backend. We need to re-install the self-hosted agent, then you can change the self-hosted agent name.
Refer to the doc about the steps to re-install the self-hosted agent.
I can fully understand your requirement. You can create a suggestion ticket in Developer Community to report your requirement.
I'm just trying to get my fist Release pipeline underway.
Our current infastrucure setup is that we have a number of On Prem VM's which I have deployed the Azure Agents as per the deployment group setup.
The issue I have at the moment is that the deployment first tries to download the artifact from our build server using a file share.
However, currently the deployment machine cant see the file share. I gather I am supposed to be able to see the file share. I'm not entirely sure how to share this folder on the build machine?
Am I supposed to just create a share for everyone to see? Or is there a particluar user/role that I am having to share it for?
Our current infastrucure setup is that we have a number of On Prem VM's which I have deployed the Azure Agents as per the deployment group setup.
You need to check which user is used to run the tasks on the agent. You can add a powershell task with inline script: whoami.
You need to make sure the account have access to the file share.
In addition, when you publish artifact, you can select file share to store the artifact and then you can consume the artifact in the release pipeline. Please check the link for the details.
My "Download artifacts from file share" in release pipeline screenshot:
I saw several pages on Internet but none that explains how to do this.
I have Azure Pipelines, a Windows self-hosted agent and an intranet TFS 2018 Server.
I tried to create a “New Azure Repos/Team Foundation Server” service connection with a full access PAT and got this message: “Failed to query service connection API: 'https: //tfs…/defaultcollection/project/_admin/_services/_apis/projects'. Error Message: 'A task was canceled.'” However, I am not even sure this is what I need.
I want a build pipeline to trigger when developers checks-in in VS2019 for a project in TFS. This pipeline would get the code on the agent, build and create an artifact on Azure Artifacts. A release pipeline would take that artifact and deploy on our intranet servers.
Is that possible?
If yes, could you help me find what must be done in Devops and on the TFS servers?
If not, could you please tell me the best way to do the above?
Many thanks
When you create a "New Azure Repos/Team Foundation Server" service connection, you can try to choose Save without verification.
If you want to check in in VS2019 to trigger a build pipeline, then you need to find the Triggers tab in the build pipeline interface, and then enable continuous integration, add Branch filters.
You can install extension TFS artifacts for Release Management in your organization. With this extension, you can deploy artifacts from external TFS. When you add an artifact, select External TFS build, and then add the required information, you can deploy the artifact to your Internal service
You can get the projectId by calling the REST API below:
REST API : https://learn.microsoft.com/en-us/rest/api/azure/devops/core/projects/list?view=vsts-rest-tfs-4.1
Extension TFS artifacts for Release Management: https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.vss-services-externaltfs
We have a hosted GitHub Enterprise (GHE) account which needs to integrate with Azure Pipelines. I have installed the Azure Pipelines app from the GitHub Marketplace for our GHE account. The installation of the Azure Pipelines app asks to select an Azure DevOps project and GHE repo to setup the integration. This results in one pipeline being connected to a GHE repo.
But my question is, how to we setup other pipelines within Azure DevOps to use repos in GHE?
Nowhere in the Azure Pipelines interface can I find an option to select a GHE repo. Only public GitHub and GitHub Enterprise (on-prem) server repos. It seems that only the Azure Pipelines app setup wizard allows you to configure a pipeline with a GHE.
I can't imagine that we would have to initiate the setup wizard of the Azure Pipelines app every time we want to connect a pipeline to a GHE repo. That wouldn't even be possible, because most coworkers won't have the permissions to do that. What am I missing?
Remark: I realize that we could create a service connection in Azure DevOps using on a Personal Access Token or username+password. But that's tied to someone's personal account. If that person would leave, the connection is broken. Unless you create a service/dummy account, which doesn't seem very elegant.
If you use GitHub Enterprise, then you can integrate with Azure AD. Then based on group membership you can assign access to repositories with the help of Github Teams.
Then based on those permissions the repos to which somebody has access will be visible during the setup of the Azure DevOps pipeline.
Some useful resources:
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-tutorial
https://github.blog/2019-09-24-azure-active-directory-team-synchronization-now-available-with-enterprise-cloud/
https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-teams
https://enterprise.github.com/support
I found out the cause of the issue.
First of all, when you install the Azure Pipelines app from the GitHub marketplace, you first need to make sure that you select your GitHub organisation and not your personal account.
Secondly, during the installation you are taken to Azure DevOps to setup your project. Two different authorization pages will be shown; "Azure Pipelines by Microsoft would like to [...]" and the page for OAuth authorization. As can be seen in below image, there is a small grant button that's easily overlooked. You need to press that button before you press the large green that says "Authorize AzurePipelines"
I am now able to select my GitHub Enterprise repositories when I create a new pipeline in Azure DevOps. I simply choose GitHub as the source where my repository lives.
I'd like to rename my organisation URL in Azure Devops. The support articles describe the impact, and what to do. But they don't mention any impact on the Azure Pipelines agent.
However, when I look at the .agent config file, there's a serverUrl property that points to the specific organisation URL.
So - if I rename my organisation URL, will it impact my agents? Do I need to reconfigure them?
Yes, it will impact your agents.
Currently, they configure to the first URL, when you change the URL they still configure to the old one and they can't connect, you must re-configure them to the new URL.
I just tested it:
The last line is when I renamed my organization, I checked also in the pool, the agent is offline. If I try to run a build I got this error: