I am trying to automate the generation of the following NuGet package using VSO:
NuGet Package
My problem is that all three "runtimes" libraries are built on different platforms. Hence, I have the following build configuration in VSO:
VSO Build
When build is completed, each agent job publish a native artifact for its platform:
Native Artifacts
My question is: Is it possible to add a 4th agent job to the build that would wait for all the other jobs and then aggregate the artifacts and generate the NuGet package with everything?
Currently, I need to manually download the artifacts and run a script to pack and sign the NuGet package. It's annoying because it require to install a certificate on my local machine and install the signing tools etc.
Thanks!
Your looking for the "Run this Job" setting on the 4th agent job. "Only When all previous jobs are complete" sounds like the value you want. You could then use powershell and/or the NuGet task to automate your process.
Related
How to use azure pipleline for creating nugetpackes and deploying to orchestrator?
The generation of the package is running with the following package: https://marketplace.visualstudio.com/items?itemName=uipath.vsts-uipath-package
In the case this is the right way what's the solution to upload them to orchestrator?
Possibility 1: Create nuget feed in azure (one feed for TEST and one
for PROD)
Possibility 2: Deploy packages to orchestrator directly
Though I am not one of the developer for UiPath, as I know, this extension hasn't integrated with our Azure Devops feed. So, your first possibility solution should not suitable in VSTS.
To achieve what you want, I suggest you pack and deploy the packages by using the UiPath Package task directly.
Create the package in build pipeline:
Create a build pipeline, add and configure the UiPath Package task by following the description here. For create the package, please choose Pack as Package action value:
Note: Please keep the default value of Output folder as $(Build.ArtifactStagingDirectory). It is the path which used to store the artifact, then got by the release pipeline.
Deploy the package to orchestrator in Release pipeline:
Create a Release pipeline, choose the build you executed previously as the source.
Add the same task into the stage, but here please choose Deploy as Package action value:
Then configure your Orchestrator info and the identity Authentication details.
At the moment I am trying to integrate the npm backstopjs into my VSTS build pipeline. To do this, I have to run it on an npm live server to get a screenshot of the actual build of the app and compare it to the reference screenshot. I tried to start this live server with a PowerShell script. This script cannot find the path to the npm root path so I cannot run the tests.
My question is: Is there a way to run BackstopJS tests with VSTS?
Edit
For the better understanding, here are some screenshots of my project:
Since Hosted VS2017 agent is the build machine provided by VSTS server, you should build VSTS with the privarte agent which located in the same machine of your live-server, so that the the build project can be searched.
And more details about deploying a private agent, you can refer the document Deploy an agent on Windows.
We've built a number of tests using SpecFlow and are using SpecRun to run the tests locally and on the build agent. Wed like to take the tests out of the build and stick them in the first release phase of the VSTS Release we have linked to the build.
The team followed the guidance from Tarun and Utkarsh to setup SpecRun in the build, but when we use the Publish Artefact task to package up all the test assemblies, they aren't found when running on the Release Agent.
When building the project on the build agent, the NuGet references of the solution are restored to the packages folder, this includes the SpecRun.Runner package which contains the Visual Studio Test Adapter to discover and run the tests.
This test runner package isn't copied to the output directory of the Test Project. The VsTest task in the build will automatically detect the test runner from the packages directory, which is why it works like magic in the build phase.
To make it work in Release we've found a few options:
ugly use the publish artefact option and publish the solution packages folder. In the release stage point the VsTest step to the other artefact location to find the Test Adapter:
better use the nuget to install the SpecRun.Runner nuget as part of the release stage. This runs the risk of the build downloading a newer or unexpected version of the SpecRun.Runner package.
best check in a separate packages.config with the reference to the SpecRun.Runner project and its dependencies, restore it during the build and attach it as a separate artefact to the build. This ensures the Release stages will be able to use the same version of the SpecRun.Runner and that the version is stored in source control.
How can I achieve CD (Continuous Delivery) for winform applications in VSTS (Visual Studio Team Services)? Currently this is what I have in my Visual Studio Solution file
1) A winform project
2) A Windows setup and Deployment project
So every time I build a winform project, I do the following steps (and I need CI / CD for exactly these)
1) Build Setup and Deployment project, which takes Build output of Winform project and creates and EXE / MSI
2) I take this MSI file and use NSIS to embed it inside EXE
3) I run SIGNTOOL from command prompt and digital sign the EXE
4) I upload this signed EXE to my website
Now how can I use CI / CD pipeline to automate the above or is it not possible for my case? I am confused. I can't find any material for winforms, all are for web apps.
Thanks
You will obviously need some sort of desktop deployment strategy. The easiest is to be using xcopy. Other alternatives include frameworks like ClickOnce, Windows Installer or Squirrel to name a few. I have a number of corporate apps that use Clickonce that I have deployed using vsts.
Now I am unable to understand how will VSTS help me with this?
Use VSTS to build the software first and include additional tasks to package your app. In my case, I use devenv.exe to generate ClickOnce packages, but you can include custom tasks by using powershell. The artifact of the build should now be the "packaged app".
Then use the VSTS deployment to copy the "package" to some kind of hosting server from where your users can download the package. That could be either a web server or a fileserver or any location appropriate for your deployment strategy.
In this context, VSTS is an orchestration tool. It helps to trigger actions for you.
See Deploy an agent on Windows to see how to setup an on-premise agent.
To build and deploy the way as you used in VSTS, you can use below steps:
Create a repository (Git or TFVC) and push your solution in the repository.
Add build/release definitions.
With CI build, enable the Continuous Integration in Triggers Tab. With CD deploy, enable Continuous deployment trigger in Pipeline Tab. The process for CI build and CD deploy, you can refer CI/CD.
Add related tasks in your build/release definition.
Build VS Installer task: build setup project with msi file.
Nsis Build Task: embedded msi file in exe.
Command Line task: to execute the signtool command. Since Hosted agent has not signtool.exe, so you should use private agent which has the signtool.exe on the machine.
Copy files task, Copy Files Over SSH task or Windows Machine File copy task: upload the file exe to your web server.
I need to execute a command line utility from a package that is downloaded as part of nuget package restore in the TFS build process.
On my local computer that is stored in c:\users\me.nuget*
I've tried every permutation of that on TFS without success. I've also tried \mydir\packages with no success as well.
The biggest problem is that I have to run the package restore step before being able to see any sort of feedback from the log. That's some slow debugging.
Any ideas? Thanks ahead.
With the latest nuget/msbuild the packages folder is held under the active user's profile directory, so an appropriate Powershell command is
Get-ChildItem $(UserProfile)\.nuget\packages
This currently evaluates on the VSTS 2017 Hosted build agent to C:\Users\VssAdministrator\.nuget\packages but by using the variable you are insulated from any changes made.
Just an addition to #Paul Hatcher's answer:
I also faced the same problem in Azure DevOps build pipeline where a specific package and nuget packages directory could not be found.
It is a Xamarin.Forms app based on a .net standard library where no packages folder exists. I later noticed in build logs that the packages are restored to nuget folder under user's profile. However this particular case is not documented on https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=vsts#agent-variables.
That means #Paul Hatcher's answer is also valid if you try to reference nuget package folder directly from your build pipeline. This ($(UserProfile).nuget\packages) should actually be a (standard) predefined build variable.
The Nuget package cache folder is in C:\Users\buildguest.nuget\packages, but it will be cleaned after build if you are using Hosted build server.
The simple way to verify:
Add NuGet restore or .Net Core Restore build step to restore packages
Add PowerShell build step to list files in C:\Users\buildguest.nuget\packages
Code:
Get-ChildItem -Path C:\Users\buildguest\.nuget\packages
Queue build and check the PowerShell step log (the packages’ will be listed in the log)
Remove/disable NuGet restore or .Net Core Restore build step > Save build definition
Queue build
The build will be failed, because the path does not exist.
So, the packages need to be restored before build solution/project if aren’t existing. You can add packages to source control and map to build agent to deal with the issue of too long time takes to restore packages.