This is a different issue as I am accessing and using my visualstudio.com server. Please see the image.
I am currently working on an automation in powershell which is to create a new project in VSTS using my account. Unfortunately, I am having an error which is below.
System.Management.Automation.RemoteException: The project collection does not have a default location for creating project portal sites configured.
Either configure this location using the Team Foundation Administration Console or specify the /w
ebapplication and /relativepath arguments.
tfpt only works with TFS2015 or more older version. It does not work with VSTS and TFS2017.
You can use Rest API to create the team project via script just as you found. Or you can also consider to use the VSTS CLI: VSTS Create Project.
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 am trying to configure the Azure Artifacts Credential Provider to allow me to connect to Azure DevOps and publish NuGet packages to the Artifacts feed. I have installed the credential provider on my build server. However every time that I run the build I get the following error:
Am I supposed to pass in a PAT to the Credential Provider or is the account that is running the build need to have access to Azure DevOps so that it can generate credentials? The documentation was a little unclear to me about how this works. My TeamCity instance is a little out of date so maybe I need to work on getting that upgraded first.
Please, add NuGet Credentials Provider build feature for your build configuration. Specify an URL for the feed (the same way as you did in NuGet Publish build step), a valid username + PAT (not a password in there).
The accepted answer seems to no longer be working. On TeamCity 2019.1.4 running on Windows Server 2016 and using .NET Core 2.2.105:
[push] WARNING: The credential plugin model used by 'C:\TeamCity\buildAgent\plugins\nuget-agent\bin\credential-provider\CredentialProvider.TeamCity.exe' is deprecated. Please contact the provider of the plugin for an alternative. More information about the recommended plugin model can be found at 'https://aka.ms/nuget-cross-platform-authentication-plugin'.
[17:18:31][push] Please provide credentials for: https://pkgs.dev.azure.com/org/project/_packaging/feed/nuget/v3/index.json
[17:18:31][push] Unable to load the service index for source https://pkgs.dev.azure.com/org/project/_packaging/feed/nuget/v3/index.json.
[17:18:31][push] Response status code does not indicate success: 401 (Unauthorized).
Manually installing and running the https://github.com/microsoft/artifacts-credprovider works from the command line if I log in to the server and set the env vars for non-interactive use, but does not work within the context of a TeamCity Build job.
Is there a newer TeamCity runner than can handle authentication for dotnet nuget push to Azure Artifacts?
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 successfully deploying an SSDT package in my VSTS release. If publishing directly from Visual Studio, there is a flag "drop_objects_not_in_source" under advanced settings. However, cannot figure out how introduce this in my CI/CD pipeline. There are a bunch of refactoring tools but none address this. So, I am stuck with object on the sql server that have been deleted.
Any suggestions?
Pass the command line argument /p:DropObjectsNotInSource=true when publishing the database or use a publish profile that contains the setting.
We're starting to automate some of our project kickoff processes. We already have a project management app (built in-house) that creates the base Solution and C# project with some default screens, authentication, etc. and populates some standard data like App Name and Namespace.
Ideally, what I'd like to wind up with is clicking a button in our project management app, having it create a VSTS project for the app, pull the template files and manipulate them as-needed, and check it all in to VSTS as a "ground zero" changeset for that newly created VSTS project. At that point, our dev team can just connect to the project and pull it down in Visual Studio.
From what I'm seeing in the REST APIs documentation for VSTS, you can get a list of changesets and files associated with a changeset, but I'm not seeing any references on adding or checking in files.
Is this something that can be done via the APIs, or some other automated extension mojo?
You can use Rest API to create a new project.
For Version Control, since you mentioned "check in as changeset", I assume you are using TFVC. The Rest API can only get the information about TFVC version control, it cannot check in files for now. If you want to check in files via API, you can consider using .NET client libraries for Visual Studio Team Services (and TFS). Refer to this link for details: Team Foundation Version Control client API example for TFS 2010 and newer. It works with VSTS too.