I have two VS solutions (test and production), mapped to respective Devops repositories.
Everything was working well, until a network crash occurred. after intranet connection was restored, I realized that Devops test repository does not recognize pending changes to my VS test solution. Instead, mapping from VS production solution to Devops production repository seems to work correctly.
I tried to cancel and re-create mappings, but Im still facing that issue. how can I fix it?
thanks
Please try the following items:
Go to web portal, to see whether you can access the test repository as normal.
If you can access the test repository, check whether you use the same account to access the repository in VS.
Close all Visual Studio instances, delete %LOCALAPPDATA%.IdentityService.
Clear Azure Devops Service caches %LOCALAPPDATA%\Microsoft\Team Foundation\x.0\Cache.
Re-launch the VS and try to connect to service again.
Check how many workspace you have and whether you selected the correct workspace.
Related
I'm trying to set Build Server machine in way that Build Agent is configured on it, and is targeting Azure DevOps Service (Cloud) collection, or organization as it is named like that for now. There is established connection but problem that I'm faced with is regarding workspaces.
When I try to run build definition, checkout step fails due to "Can not determine workspace..." error. As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story. I have to run the mentioned command again (new workspace is appeared in the list) and then I'm able to build that project.
Can someone point me on right way in diagnostic or tell the cause/solution if faced with this already?
According to the description and this thread which i assume is also posted by you,seems the agent in Azure DevOps is the one you used in TFS which is called as migration.
As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story.
It looks like the build definition requires a specific workspace which you managed by manual command.
What about create a new agent in Azure DevOps which is quite simple see if the problem can be resolved.
I cannot deploy a release in Azure DevOps Server (on-premise). Whenever I do, Azure DevOps Server shows a "loading" spinner and hangs:
The spinner is shown forever:
There are two other users in our team who share the same issue I have. I've been assigned Azure DevOps Server Administrator rights, still I cannot deploy, so it isn't a rights issue.
I've been logging into another Windows machine, been using other browsers ... yet, to no avail. I always get to see the spinner only.
Strange enough: Other users in our team can deploy releases in our project flawlessly. Currently, it's only three persons in our team who observe Azure DevOps Server hang. Even we could deploy releases until two weeks ago. No-one has changed anything. It suddenly stopped to work for three of us (me included).
I suppose it's a bug in Azure DevOps Server.
What's causing this behaviour? How can we cope with it?
EDIT:
These are the JavaScript warnings I get to see when using IE 11:
It seems like the error is based on the fact that we separated our boards from the repository in Azure DevOps.
In Azure DevOps we created a common board for all projects, but we left the projects themselves in their own Area. Then we moved the boards' items to the new overall board while we left the repositories at their original location (Area).
This seems to cause the hang when a repository's board gets disabled.
Re-enabling the repository's (now obsolete and redundant) board solves the issue.
I created an Azure Functions 2.0 (C#) project in VS 2017 and put it in GitHub. If I publish to Azure directly from VS, it works just fine. Then I accessed Azure Portal in order to configure Azure Functions, and there is this option to deploy from GitHub. I configured this option and when I commit something to GitHub, the Azure Portal detects and start some process (in Deployment Center there are logs with "success" status for each change I made in GitHub) but the code isn't deployed.
Any ideas?
Thanks, guys! I found the problem! I first published my solution directly from Visual Studio to Azure. Then, all functions became read-only, so build process did executed with success, but the files aren't updated.
I erased my functions app and recreated manually, and configured deployment with Kudu, getting from GitHub, and then everything works like a charm! Each commit in github updates my app!
Make sure Visual Studio is connected to GitHub to push the azure function
In the deployement center , you need to check that deployement is connected to github
You also need to check the Azure function version 2.
Step by steps guide Referenced from my article
Continuous Azure function deployement from Github using Kudu Build Server
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
When using visual studio online, we want to ensure that contractors or developer working on project could only check-in and check-out using our given laptops.
Has anyone found a way to restrict access to code from a certain machines in Visual studio Online?
Can we somehow log who checked code out and from which machine at what time?
There is currently no way to restrict access to VSO by IP address. It is something we are considering. What you can do is to enable two-factor authentication in your Azure Active Directory tenant.
There's no way to currently log who has checked out code. The closest you could get would be to periodically query for the workspaces in the account if you are using TFVC. There's no way for you to track clones of Git repos.