Where can I see the system capabilities of hosted agents? I went here and it only shows user capabilities:
https://dev.azure.com/{myOrg}/{myProj}/_settings/agentqueues?agentId=8&queueId=91&view=capabilities
Trying to find versions of msbuild and paths to it on the computer. I need to use version 16
You can check the tools and softwares installed on the Microsoft hosted agent here. Click the Link shown as below screenshot to see the included softwares.
Unfortunately msbuild seems not installed separately, as it cannot be found in above hosted agents. But you can directly use Msbuild task and specify the msbuildVersion to 16.0 in your pipeline. The pipeline will automatically download the specified version msbuild from the cloud.
And also you can build your own self-hosted agent to run your pipeline. and manually download msbuild version 16 to your on-premise machine. So that you can specify the msbuild location in msbuild task to your on-premise msbuild location.
They have actually open sourced the Hosted Agents and you can find out all the information required from the repositories:
https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/pipelines/agents/hosted.md
The have links for each of the Images that are available at this link:
https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/pipelines/agents/hosted.md#software
Windows2019-Agent
https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md
You can also add Demands to Agents:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml
This can be used to ensure the agent has your the specific software needed for your builds.
Related
I have a suite of working Coded UI tests, written in C#, all marked as [TestMethod], written in VS 2013 and running on a set of VMWare machines, using the MS Test Agent (version 12.0).
I am building a release pipeline in Azure DevOps and use the following tasks:
Visual Studio Test Platform Installer (selected version 15.9.2)
VsTest - Test Assemblies (selected Visual Studio 2015 as this is the lowest version)
All of the test DLLs are at a specific folder on the VM I'm running and they are all copied from the deployment folder of an actual working VMWare machine. The test directories of the tasks are pointing to that folder.
I tried running .orderedtests file in the test assemblies section of the VsTest, but got an error that no tests were found.
I then switched to a *.dll so I can just see some tests recognized and running.
At this point I just want to see tests running. I don't care for the results.
In this scenario - letting the VsTest task discover the available tests, I get the following error:
##[error]The slice of type 'Discovery' is 'Aborted' because of the error : System.Exception: No test is available in [some
folder]\Some-File.dll. Make sure that test discoverer & executors are
registered and platform & framework version settings are appropriate
and try again.
What am I missing and what is needed to be able to run those 2013 (12.0) tests, which are working perfectly on local VMs, on the Azure DevOps pipeline?
Thanks!
The slice of type 'Discovery' is 'Aborted' because of the error : System.Exception: No test is available in [some folder]\Some-File.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
Based on the error message, you can try to can specify the appropriate framework and platform in the vstest task.
For example:
/Platform: x64 /Framework: framework40
For more info, you could refer to this doc: VSTest.Console.exe command-line options
On the other hand, since you can run the test on your local machine successfully, you can also try to use the self-hosted agent.
I read about Microsoft Visual Studio App Center, but it seems to only apply to developing native apps.
I need to realize a Selenium-based CI/CD workflow, like this:
Programmers develop a web application locally, pushing their changes to a local GitLab repository.
The on-premise "service" watches the GitLab repository for changes. If changes have been detected, then:
Pull project.
Compile project in Release configuration.
Run NodeJS unit tests and validate results.
Deploy to on-premise test site.
Using local (non-public) URLs, run Selenium web tests in parallel on different devices (e.g. Windows 10 desktops, tablets and smartphones; Apple tablets and smartphones; Android tablets and smartphones) with different browsers (i.e. Edge, FireFox, Chrome, Internet Explorer) and validate results.
Using "local" URLs stands for something similar to BrowserStack Local.
This includes the ability to take screenshots and to compare them to reference screenshots of a previous test on the same device/browser.
Show test results of all the tests.
If all the tests have run successfully,
Request confirmation to deploy to production site.
Deploy to production site.
Does Microsoft offer on-premise services for this? Which are they?
You can still get TFS from Microsoft as an On-premise variant of VSTS. Both have the same codebase, but the SaaS variant is released more often (every three weeks!).
VSTS/TFS can handle Git repositories out of the box, with all steps you described. Even uploading a new software version to all the stores :-)
I have setup a Linux Srv in Azure with OMI/PSDCS and trying to deploy with VSO Release Management.
I have created an Azure environment (I won't allow mw to create a Standard Env) and solved all certificate issues so far.
Now it's failing because RM try to connect to the linux server using Negotiate Auth and (of course) the OMI service only supports Basic.
How can I make RM to use Basic? Or OMI to support Negotiate/NTLM?
Any post or document showing ANY working VSO RM deploying to Azure without using Chef?
The "Run PS/DSC task" that ships with RM does not support Linux deployments. The current implementation is quite dependent on Windows being the target. But, may I suggest a couple of workarounds?
For both of these workarounds, you should first have a PS script (with DSC configurations and Start-DSCConfiguration) that you can run from a Windows machine to target your Linux machine, without using RM or Build. You have complete control on how this script should be written including how the credentials are created, and the authentication method.
Once you have an independently tested PS script, you can do one of the following:
Create a Build definition in your visualstudio.com account Build hub and use the Powershell Build step to run the above script. Note that this is the new Build system in VSO. It has the ability to run PS scripts easily. Note that you are creating a build definition here instead of a release template in RM. The new Release hub that will be available later this year in VSO will be very similar to the Build hub, and you can leverage the same PS script inside a Release definition once that is available. I tried this approach and it seems to work fine.
Setup a Windows machine as a target Azure environment in RM. Create a vNext release template to then run the above PS script on the Windows machine. When that script is run, it will be able to target the Linux server. In this approach, you are using a Windows machine as a proxy to run the PS script. I have tried this using agent-based release template, and not with the vNext release template. I am hoping that it will work fine with the vNext release template as well.
I'm trying to deploy a two-websites project in a Visual Studio 2012 solution via TFS as part of a build. We're at the point where we have two different web servers, WIP (work in progress) and DEV.
We want to deploy different connection strings to either server so they can connect to different databases. We've tested our solution on a development machine with Visual Studio and for all configurations, when any web project is published, the web.config connection string is transformed as expected when we check the web server.
The build is working fine on the WIP server which uses the default Debug solution configuration. The configuration in the TFS Build is Any CPU|Debug.
For the next configuration (DEV), we are sure that the web projects both publish via Visual Studio 2012 to the web servers and that the web.config files transform.
However, when we run the DEV build using MSBuild arguments, we notice that no transformation happens. We've sent the configuration in the Items to Build section of the build to: Any CPU|Dev.
/p:VisualStudioVersion=10.0 /p:DeployOnBuild=True;PublishProfile=app.ui.dev.pubxml /p:DeployTarget=MsDeployPublish /p:MsDeployServiceUrl=https://server-dev-hrtech:8172/MSDeploy.axd /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=WMSVC /p:AllowUntrustedCertificate=True /p:Username=username /p:Password=password /p:_WPPCopyWebApplication=True /p:PipelineDependsOnBuild=False
When we look at the build log and output directories - we can see compiled assemblies in the obj/Debug directory and not the obj/Dev directory as we'd expected. In the logs, we can clearly see /p:Configuration="Dev" as we'd expect.
The bottom line is the published web.config that ends up on the web server is the default web.config file from the Debug configuration (that is, untransformed). It is as if MSBuild is unable to see the configuration parameter passed in the arguments for the solution.
I've now tried running msbuild from the command line on my development machine to try and understand why this would happen.
By stripping back the MSBuild parameters that are sent via the TFS build, I can see that this doesn't transform the web config:
msbuild "app-no database.sln" /t:app_ui:Rebuild /P:TransformConfigFiles=true /p:Configuration=Dev /p:Platform="Any CPU" /p:MSDeployServiceUrl=https://app-dev-hrtech:8172/MSDeploy.axd /p:Username=username /p:Password=password /p:DeployOnBuild=True /p:PublishProfile=app.ui.dev.pubxml /p:VisualStudioVersion=11.0 > build.log
I can modify this and use MSBuild to build the project file directly. I've discovered that the command below does transform the web.config file for the published application:
msbuild app.ui\app.ui.csproj /p:Configuration=Dev /p:MSDeployServiceUrl=https://app-dev-hrtech:8172/MSDeploy.axd /p:Username=username /p:Password=password /p:DeployOnBuild=True /p:PublishProfile=app.ui.dev.pubxml /p:VisualStudioVersion=11.0 /p:AllowUntrustedCertificate=True > build.log
The problem is this would be difficult to run as part of a TFS build where they are multiple projects which some for websites and others for Windows servers, etc.
How can I use the first command, but amend it so that it properly transforms the web project?
As you can see I've created some publish profiles, so potentially they can be used in the MSBuild arguments as well in the TFS Build.
PS: we're using Visual Studio 2012, TFS 2010, Windows 2008R2 for servers and Windows 7 for development machines.
I've encountered this problem, regarding how to publish a web site through Publish Profile file, this article is the best one I ever saw.
For you case, it seems that you need to make the profile name same as the configuration name, e.g. use Dev.pubxml and Web.Dev.config.
/p:DeployOnBuild=True;PublishProfile=app.ui.dev.pubxml
I dont think that .pubxml should be at the end of the profile.
Should be like this
/p:DeployOnBuild=True;PublishProfile=app.ui.dev
It looks like TFS 2010 Build doesn't call the Transform MSBuild task by default. You need to edit either your TFS build defintion to add a new activity which calls it or edit your project file to do this.
Stack Overflow question TFS Build not transforming web.config as expected should help you with adding the new acitivty and blog post Integrating Web Config Transformations with TFS Build for making changes to the project file.
I just had this problem. Checked the MSBuild logs, checked making a local ZIP package, checked Web Deploy push to remote IIS and it was always using the default config file!
Turned out that the lump of XML I was looking at to check for my QA settings was lacking the xdt:Transform="Replace" attribute!
Hope this helps someone.
Is there a way to have MSBuild create an instance of IIS on another remote machine?
I do the builds (which occur locally using TeamCity AFAIK), but would like the code to be pushed up to our testing server once the build is completed. I am using IIS 6.x (Windows XP dev and Windows 2k3 Server for testing).
Did you check out MsBuild Extension Pack? It has a task called MSBuild.ExtensionPack.Web.Iis6Website wihch can be used to create a web site.
Disclaimer: I have never actually used that task with remote support, but the documentation claims is it supported :)
EDIT: you could also have a look at the WebDirectoryCreate task in the MSBuild Community Tasks project.
Another option is to use MSDeploy (which you can call from MSBuild). With MSDeploy you can install a Remote Agent Service which listens for actions to be executed on the target IIS server.