I'm trying to run a request through the TFS REST API v2.0 because I would like to be able to modify the 'ProcessParameters' of a specific BuildDefinition before triggering it. This is so I can pass an argument to the specific BuildDefinition's deployment script.
Doing this work through the TFS SDK works fine, but I've had to refactor to use the REST API instead because this has to run on a production machine without Visual Studio and TFS Team Explorer.
The documentation says I should be able to specify a propertyFilter in my query, but I'm unable to get it to return more information. What I am getting is very light compared to what I'm used to working through the SDK.
Here is my request: https://{instance}/DefaultCollection/{project}/_apis/build/definitions/{id}?api-version=2.0&propertyFilters=processParameters
The response is exactly the same whether or not the "&propertyFilters=processParameters" part is set. It should be able to handle a comma-delimited list of property names but seemingly it is just ignored.
Have I found a bug, or shall we say, a discrepancy between the API documentation and the actual API? Is the 'propertyFilters' query parameter actually implemented? I can't get it to work...
Any help is highly appreciated!
It seems that you are working with XAML build definition as vNext build definition does not have ProcessParameters. However, the RestAPI Build 2.0 is mainly designed for vNext build, it can only get some basic information for XAML build definition. That means, Rest API cannot achieve the features you want for now if you are working with XAML build definition. You have to install VS&Team Explorer and use TFS SDK to do it.
Related
When one creates an ASP.NET Core Web API in Visual Studio 2022, and tests it locally, one gets a convenient Swagger page built upon an OpenAPI definition, to test all HTTP endpoints.
However, when deployed and trying to access {path-to-api}/swagger, it returns a 404 Not Found error, even while on localhost, when both the API and the database is sitting on my own machine. Even if the database is in the Azure cloud, for that matter, it also works, if I put the Azure SQL Database connection string into appsettings.json.
So is there a way to achieve this, preferably without too much hassle? Or am I wrong in wanting this, do developers mostly test their APIs locally? Because I want the Swagger API online only for testing.
The problem is getting and using the swagger functionality into the cloud. Is it possible and good practice?
If you look at the startup, you will notice that the swagger is only loaded during a development session via an if check. Commenting that out, or expanding it based on evironment, will allow a published version to generate the page on the target host.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
I generally do that for first publishes or to Dev/Test environments to see it running. Once it is not needed, I un-comment it back in.
Also it may be actually viable (turned on) in Dev or UAT server because one is also publishing the open api it to APIM (Azure api manager), which takes the api and generates its own development environment; away from an initial publish.
Also once published, it is not the default page, one still has to path to it such as .../swagger/index.html.
I'm aborting this mission to deploy the Swagger interface to Azure along with my API. It's bad security practice to make the HTTP request methods so visually available to all. So the answer to my question do developers mostly test their APIs locally, is apparently yes.
I wondered if I should remove the question, but I would like to make it still stand, in case anyone else is contemplating about doing the same thing - exposing an API online with the Swagger UI.
We have created a process template on the Enterprise level access on Microsoft AzureDevOps platform. We were looking to export the process template so that it can imported for some other organization. However we do not find an option to do so. Can anyone help?
The only way I've found so far to export inherited processes to other organizations is to use the process-migrator tool that's on GitHub made by Microsoft. There are some wonky things about it that don't totally work but hopefully should be a good start:
https://github.com/Microsoft/process-migrator
You download and install dependencies on the tool then you can run migrate or export/import (I think I usually do export/import).
I think that it works okay as-is except for if you have work item rules that are type CurrentUserIsMemberOfGroup, and picklists don't export correctly, but you'll want to do some testing of the tooling first. I also found out recently that this tooling uses an old SDK/API version (API v4.1) so hopefully it will be updated soon.
I am not sure through Azure DevOps UI but there are methods in Azure DevOps Services REST API
Export Process Template REST API Documentation
Import Process Template REST API Documentation
Parameters are pretty straighforward and well explained in MS Documentation.
I have a web api (REST) project that is written in .NET and I have written a few webtests (.webtest) that test those apis.
While those tests run fine locally from visual studio, I want to integrate them into my VSTS (Azure Devops) build pipeline, so as to identify and breaking changes that could break any of those APIs.
I am not able to find any task in build pipeline which can run the webtests as part of build. I see option for running unit-tests though.
So, wanted to check what am I missing here.
You might want to find an alternative approach as this link implies it has been deprecated.
Visual Studio web performance test (.webtest file) is tied to the load
test functionality and is deprecated. Some customers have used
.webtest for other purposes such as running API tests, even though it
was not designed for that purpose. Many API testing alternatives are
available in the market. SOAP UI is a free, open source alternative to
consider, and is also available as a commercial option with additional
capabilities.
You could try to use cmd task command line to run MSTest with arguments.
Add Run Command Line step/task to execute MSTest command
Add Publish Test Results step/task
On the other hand, you can do test in Unit Test too, just send the request and check the response, related thread.
Also as Matt mentioned, since Visual Studio web performance tests (.webtest files) are tied to the load test functionality and is also deprecated. You could take a look at this blog here: Cloud-based load testing service end of life
I'm not sure if I'm searching correctly, but I'm hoping I can get some guidance here.
Current Setup
I have one solution with two projects:
Web API project
Node.js project
I'm using Azure DevOps with 2 Builds, each with their own Releases, one for each project. Each build definition only triggers when their respective project is updated/changed.
This works great!
I've noticed that each build actually builds the entire solution. In order to not waste processing power, I'd prefer to have each project only build their own project, with a few caveats.
The Web Api project does not depend on changes to the Node.js project, however, the Node.js can depend on changes to the Web Api. Because of this, if the Web Api fails, I don't want the Node.js to build/release.
Goals
What I'm trying to do is setup my build definitions so that the Web Api build, only builds the Web Api project. Whether it completes or errors out, let the build proceed as it normally does.
However, I want the Node.js project build both the Web Api and the Node.js project, so that if the Web Api build fails, then the whole build fails even if the Node.js would not have failed.
I've tried adding a new Visual Studio Build task and select the project only, but I got the following error:
[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(781,5): Warning : The OutputPath property is not set for project 'MyProject.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='release' Platform='any cpu'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
I'm currently looking on how to fix this, but I want to pose the following questions in case I'm headed in the wrong direction.
Questions
How can I setup the build definition to only build 1 project?
Is there a different configuration I should be creating instead of the one I mentioned?
Build Definition
What I'm trying to do is setup my build definitions so that the Web Api build, only builds the Web Api project. Whether it completes or errors out, let the build proceed as it normally does.
This is the case where you want a build definition that is targeting the project file instead of the .sln. Your error is that building the .csproj requires the OutputPath property to have a value, so just add it to the MSBuild Arguments box: /p:OutputPath="$(build.binariesDirectory)\MyProject". Build.BinariesDirectory is a predefined variable, but is otherwise not a required directory value. You can use what makes sense for you.
I want the Node.js project build both the Web Api and the Node.js project, so that if the Web Api build fails, then the whole build fails even if the Node.js would not have failed.
The simplest and least sophisticated way
From what I understand about your situation, this case doesn't require any additional changes. If you build the solution, then the pipeline will fail if either of the projects are broken. The downsides to this are:
The Node.js project doesn't "get" the newest changes to the Web API "dependency" until the Node.js project is changed and CI triggers a build
If you use a build completion trigger to mitigate downside 1 above, the Web API project gets built twice even though we know it should be successful both times
The more complex and sophisticated (but elegant?) way
Set a Build completion trigger on the Node.js pipeline that will trigger a build when the Web API pipeline is successful. This is similar to what you have now with some differences. With build completion AND a CI triggers on your Node.js pipeline, the Web API build can succeed regardless of the result of the downstream Node.js, but you will be building the Node.js project even when changes are not made to that project explicitly. (This may not be what you want if you're trying to save on agent activity)
Your Node.js pipeline can then have 2 separate build steps, each targeting one of the project files. However, the step for the Web API project build can have a condition to NOT perform if the Build.Reason is BuildCompletion. This allows the Node.js to be a downstream project of the Web API, but doesn't build the Web API if we already know it's successful.
Note: depending on how your references work between these projects in this solution, you may need to add other tasks for downloading the build artifacts and what-not to make sure everything is where it should be for building.
I have a Azure project (Azure 1.3) in VS2010. There are 2 webroles, one web page project and one WCF project. In debug mode I want the web project to use a web.config for DEV enviroment, and when publishing the web.config for PROD must be used.
What is the best way to do this ?
Currently I am facing issues when using a Web.Debug.config with transform XSLT. It doesn't seem to work in Azure....
Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.
What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.
I agree with Mose, excellent question!
Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.
The canonical example is "I need different database connection strings for development and release" but it also fits your situation.
There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
I like this question !
For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :
bot.cloud.config
bot.dev.config
bot.win.config
This is incredibly efficient !
I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :
Both config are not in the same place, which is time-consuming when debugging
You have to learn a new way of writing something that sould be standard
Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error
I'm still searching the right way to do that, like in this post
Another possible solution is to have two CloudService projects, each one with specific ServiceConfiguration.cscfg(dev/prod). Develop using the Dev, but deploy the Prod.
Currently I am facing issues when using a Web.Debug.config with
transform XSLT. It doesn't seem to work in Azure....
It depends on whether you want to make it work on your local machine or inside continuous integration.
For the local machine I tried to answer here: https://stackoverflow.com/a/9393533/182371
For the continuous integration it's even easier. When you build from the command line specifying the Configuration property value your configs WILL be transformed (no matter what it does when you build inside VS). So properly specifying build configurations for both cloud and web project will give you the correct output depending on build parameters.