We have started using Appveyor for CI with our Github repo and all has went fine. We have our build script working (appveyor.yml) in the repo, and it successfully builds and produces an artifact. Now on to my question
We are trying to pair our builds now with codecov.io which says it will scan it during the CI build. And it does support appveyor, it merely says to add this to the yml
after_test:
- bash <(curl -s https://codecov.io/bash)
Which we did, but nothing happens. Does this mean i need an actual test script to run, before it will send off the code to codecov? It is a C# project, and we have it compile, and generate the .exe which we then package into a zip which can be downloaded.
What are the point of these "test scripts" when we already know it compiles and produces an exe? I am a bit confused on how to use this properly..
I believe here https://github.com/codecov/example-csharp is good example of running codecov tests on C# project with working Appveyor configuration. Please look at readme.md file in that repo for greater detail.
From the Documentation
You need to add the OpenCover nuget package to your Visual Studio solution which is used to generate code coverage analysis:
PM> Install-Package OpenCover
Secondly, you need to either write a PowerShell script (if you intend to generate code coverage and upload the result interactively) or you need to add a few entries in you CI config file (if you intend to let your CI generate the coverage).
Related
PreInfo: I have .net core web api (vs2015) mixed with just ordinary projects.
I have spent almost 2 days now to get this to work and search and tried everything I can think of, but I just cant for the live of me get the build and release in TFS online to play together.
The build (publish artifact step) says "Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'."
but the "run dot net" step says
"Published to D:\a\1\s\Operator\MobileService\root\MobileService\src\AMP.Operator.MobileService\bin\release\net452\win7-x64\publish"
...so it must be somewhere the release can pick it up but no matter what I try I can´t get it to be picked up.
Here is my build setup
dotnet run
publishing
And the realse with $(System.DefaultWorkingDirectory)/MobileService-Dev please note that I have tried every combo of $(build.artifactstagingdirectory) in the build to publish without luck but I sure this should point to the publishing folder for the build
I so hope somebody can point me to a solution. I just can´t understand how hard it is to make this work..
Within your build definition, I recommend adding a Copy Files step that will copy your the build artifacts from your msbuild results to the Build's Artifact Staging Directory before you run the Publish Artifact step.
Source Folder: $(Build.SourcesDirectory)
Contents: **\bin\$(BuildConfiguration)\**
Target Folder: $(Build.ArtifactStagingDirectory)
I am assuming that the $(BuildConfiguration) variable is custom to your definition and is probably Debug or Release. I am not sure what exactly the Run dotnet step does, but this build definition I setup published my build artifacts correctly. The Publish Build Artifacts step I'm running has the same steps as yours, except the only control option enabled is Enabled.
I am also running on TFS 2015 update 2.
You can download the files if you just want to take a look at them. Go to the build, click on the Artifacts tab, and then download as shown below:
You need to specify output argument (--output/-o) for dotnet publish command.
Arguments:
Publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)
BTW: You said “run dot net” step says “Published to D:\a\1\s....”, the files are in D:\a\1\s, no files in D:\a\1\a (one is s and another is a).
I am trying to get TeamCity to build less files and generate my bundles.
Is this possible in Team City?
Sure it is. Anything you can run from command line you can create a build step for. So, you need to find a script you can trigger from commandline (MSBuild for example, there's even a build runner for MSBuild). I would probably collect all build files as artifacts that I can later download directly from TeamCity. Something like this (all separate build steps):
Build everything
Generate css files and bundles (maybe part of step 1).
Generate msi file using something like WiX.
Collect artifacts within TeamCity.
This is a very nice setup, in my view. Probably you need to ask for more help on each step separately.
Good luck!
I have been playing around with TeamCity to get a CI environment up and running.
I started by following Troy Hunt's 'You're deploying wrong', which was very useful, however I wanted to split the packaging and deployment into 2 seperate steps, for the following reasons:
I wanted to pass some additional flags to msdeploy, which isnt possible (to m,y knowledge) by using the MSBuild Package and Deploy that Troy describes.
I can easily disable the Second Build Step i.e. deployment, if I ever need to build the package but not deploy it.
I wanted to use the -skip flag on msdeploy to prevent it from deleting certain folders, which again I couldn't find any method of doing without passing as an argument to the command line.
So, in my first MSBuild step I just have the parameters:
/P:Configuration=%env.Configuration%
/P:VisualStudioVersion=11.0
/P:IgnoreDeployManagedRuntimeVersion=True
And then I have a second Build Step that uses a command line build runner to execute the following msdeploy command:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="C:\ProgramData\JetBrains\TeamCity\system\artifacts\MyProject\%system.teamcity.buildConfName%\%teamcity.build.id%\MyProject.Web.csproj.zip" -dest:auto,ComputerName='https://devserver:8172/msdeploy.axd?site=MyWebsite',UserName='domain\username',Password='password',IncludeAcls='False',AuthType='Basic' -skip:objectName=dirPath,absolutePath=media$ -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2 -allowuntrusted
The problem with this is that apparently TeamCity doesnt publish the artifacts until all the build steps are complete, so therefore the Command Line process fails because the package zip file doesnt actually exist at that point.
I have read something about publishing artifacts whilst the Build is still in progress but that does seem like a bit of a hack.
Any advice would be greatly appreciated.
You would be better have two builds vs two build steps.
The first (Build A) would have 1 build step that would do the building then the second (Build B) would just do the deployment in one build step using the artifacts from the first.
So under the first configuration tab of build A, you would specify the artifacts that would need to be made available from the first build. You can then run the build and confirm that under the artifacts section everything you need is available. (These will show when build A has completed running).
Then under the dependencies section (Can't remember the exact name, and I'm away from my TC instance) of Build B you can set it up to use the artifacts of build A which would then be used for the deployment.
Once you have all that working, you could add a build trigger to have Build B run after a successfull execution of Build A, then if you at one point just wanted to run Build A, disable the trigger on build B or pause the Build B configuration which will stop the trigger from firing.
I've been charged with coming up with a workflow in a non-TFS build tool that will build a solution, run unit test projects in the solution, then package the final output of the build for deployment. I originally had constructed a workflow that used MSBuild with the Outdir parameter to get the publishable application for later storage. When I added unit test projects to the solution they work fine in Visual Studio (2010) but when I run my solution through MSBuild the MSTest step can't find the tests because the VSMDI file points to the BIN folders in the test projects, but the Outdir parameter is applied a the Solution level so the test DLLs are constructed in the Outdir directory instead of the BIN folder. If I remove Outdir from MSBuild the tests run, but I don't get a publishable application. This is a problem for web applications where we don't want to publish the code files and other artifacts that Visual Studio Publish would exclude.
Any ideas how to get MSTest to run the tests correctly based on the VSMDI file when MSBuild is run with Outdir? I thought about scripting an XML transform to change the paths in VSMDI to the Publish folder, but that seems like a hack.
Any suggestions are greatly appreciated.
You could abandon the vsmdi file all together and pass the dlls in a list to the commandline tool?
Otherwise id plum for the transform. The transform is not as bad hack as you think because at least you know the devs are running the same tests as your build and you'd have this problem as it occurs when you try to build, test and package the release version.
I have a build.proj, that is a MSBuild file and can be run locally.
All I need from TFS is
Get the sources from TFS Source Control.
Call "MSBuild.exe /t:Deploy".
Update the build status based on the result of MSBuild.
I have tried to make a template combining the DefaultTemplate.xaml and UpgradeTemplate.xaml.
But so far, no luck :-(
Can someone help me make this template?
If you select the upgrade template that comes out of the box when you create a new TFS project with 2010, you can supply your old TFS2008 proj (MSBuild) file without problems. Please read http://msdn.microsoft.com/en-us/library/dd647553.aspx for more details.
You should use DefaultTemplate. I had the same problem and I solved it this way.
You can do it using UpgradeTempate also, but using DefaultTemplate was easier for me.
On Process section follow these steps:
Select Default template
Add your project into Items To Build collection
Set MSBuild Arguments (Advanced section) to "/t:Deploy"
I have MSBuild project file for running builds locally. This script is used also for sever builds. I have three MSBuild projects in Items To Build collection. One for PreBuild step (some checks before build is executed), main build script used also for local build and the last script for additional post build tasks (deploy process). I'm setting additional MSBuild propertires like IncrementalBuild and ServerBuild properties in MSBuild Arguments.