I want to accomplish following flow:
All commits are built by AppVeyor and .nupkg is created with version for example 1.2.3-{build}.
When I decide code is stable enough, I want to manually deploy it to NuGet with version 1.2.3 (without build number suffix).
Then I change env variable from 1.2.3 to 1.2.4 and process is repeated.
I have almost complete AppVeyor configuration, but I encountered following problem:
AppVeyor tries to deploy every build to NuGet. I want to be able to manually pick which builds I will promote to stable and push them to NuGet.
How can I make AppVeyor not deploying any build without my action?
You probably need to use Environment instead of Inline deployment. Difference is described here
For your scenario you can simple remove deployment from build and create new NuGet deployment Environment to manually call is against specific build when needed.
Related
We are experimenting with using Octopus for CD using TeamCity. We have enabled OctoPack to create the Nuget Packages for use during the deployment. We also are experimenting with building libraries and using the integrated Nuget Server.
We were able to do both successfully. Both deployment to an environment, and using Nuget.Config to both install the library package and restore and build in TC.
Yesterday, the CD stopped working, the packages are being built but the Nuget Server is not making them accessible. We reset metadataBuilds, per TC instructions and we are still not getting new packages in the feed. We did confirm that the packages are still being built.
Any ideas?
I would say a starting point to get a solution to this depends on where the nuget packages are stored when your solution is built in TC.
If they are left on the TC Nuget feed, then you would want to watch to see if there are more than 100 packages in the Nuget store (TC Artifacts). We have found that once you go over 100 packages, the ones after those 100 do not show up in the feed when Octopus tries to pull from it.
If you are pushing to the native Octopus Nuget store, perhaps watch to sere that the space on that server hasn't filled to the point where it cannot push any more of them.
The build log in TC should tell you a lot about where and how these packages are being dealt with. They should also show up as build artifacts after a build, which would allow further verification that they are at least being built.
Although it may not be related, the Nuget feed in TC may take a while to pick up new packages after a build finishes. Particularly once you get a large number of packages. That may cause Octopus to fail if it is kicked off right afterwards (by a chained build).
What I've found works best is to push deployment packages directly to the Octopus internal nuget store, and keep shared (referenced in other projects) in TC or another nuget server. (NB you cannot use Octopus as a nuget server to retrieve packages). The push is done as an explicit step in the build that produces the packages.
I have just setup TeamCity to automate our builds, our current solution has both a dev and main branch. What I am trying to achieve is to have the development branch build and publish to a development NuGet feed on our ProGet installation, and then have the main branch publish to our Main NuGet feed on ProGet server.
We are using octopus deploy to deploy the packages, within TeamCity we have the octopus deploy plugin installed and if I tick the box to run OctoPack it builds the packages and they appear as artifacts when the build completes. If I try to use the NuGet Pack build step in TeamCity I get the following error for one of our projects:
[08:33:49] : [pack] Attempting to build package from 'xxx.csproj'.
[08:33:50]W: [pack] Unable to find 'xxx.exe'. Make sure the project has been built.
The project has been built and it works with OctoPack so why isn't it working with the NuGet Pack? Wwe have five projects being built and the first four run fine, one is a console app, one is an mvc website, and two are class libraries. The one that doesn't work is a windows service.
The end goal here is to publish these packages to a private feed on ProGet. I don't mind using OctoPack but in my head wanted to remove that dependency from TeamCity but I can live with it. However when I try to use the NuGet Publish runner type how do I select to publish any NuGet artifacts that have been created?
I have been googling like mad and I cannot find any helpful links that describe what you are supposed to enter, I would really appreciate any helpful comments/answers.
We are using version 8.15 of TeamCity.
Hopefully the following will help with at least part of your question; mainly the bit relating to how to publish packaged artifacts.
NuSpec Approach
When using the NuGet Pack build step, you can specify the Output Directory, which will determine the output location of the packages. You can specify this as a relative path to the checkout directory, probably best to define it as a build parameter, such as %system.PackageDeployOutput% as you'll be using it in the next step...:
Next, specify a NuGet Publish build step, fill in the Package Source / API key etc, and specify the Packages to upload as
%system.PackageDeployOutput%\*.nupkg
This will pick up the packages output in the previous step. I've used this quite effectively, and the parameterisation approach encourages conventions across all your builds.
OctoPack Support
If you're using the MsBuild build step with OctoPack, you can use a similar approach by declaring a system parameter called
system.OctoPackPublishPackageToFileShare = %teamcity.build.checkoutDir%\%system.PackageDeployOutput% (note the same parameter as above)
You can declare these as root project parameters, so you get the best of both worlds. My preferred approach to packaging is currently to use nuspec files for deployable endpoints. I've found OctoPack to be a bit of an overhead when it comes to more complex deployments (it's fine for basic MsBuild projects).
We have a very project, and we decided to build it's core as a set of NuGet dependencies using TeamCity. And now we want to import those NuGet packages to the rest of project.
Core can be updated several times a day, and project must use only the latest version. But when we removed version specification or set it as version="", it still used the old version.
So, we want our project to use the latest libraries on each build. Can you post some recomendations?
If you can rely on just TeamCity you could take a look at the NuGet update options that TeamCity provides. They have build options such as Update packages with help of NuGet update command which you could try.
If you want something similar when you build on a developer's machine then you will need to look at some pre-build step that uses NuGet update.
Our build plans for Sitecore (.Net) websites are currently using Bamboo as the build plan master for continuous integration process. Bamboo supports building a .Net project, and that .Net project contains references to several Sitecore binaries.
I have used NuGet as an artifact repository, mostly because that seemed to be the one most people were using.
So, now that I have a nuget repository, am hosting my own feed, and have added the Nuget package to my project (I just installed the package of binaries I created), what more do I need to do?
Should the build call out something special, or am I done? I guess I'm just nervous that bamboo isn't talking directly to my repository....
In the closest analogy I have, namely a Maven/Archiva combo, the maven plan specifically references the artifacts in archiva, pulling the correct version as needed. Does NuGet do this?
Since there have been some new developments in the NuGet package restore approach, I thought I'd post an update on this topic. We're using Visual Studio 2012. I wanted to be able to run MSBuild and make sure that it would first restore NuGet packages without setting "Package restore" to true in the config. Here's what I did (inspired by https://stackoverflow.com/a/23935892/414376):
Upgraded NuGet in my solution to a version later than 2.7 (2.8.3 in my case; this seems like an optional step)
Installed NuGet.exe on the build server
Added NuGet.exe to my remote agent so that it could be run as a command from Bamboo
Added the NuGet command to my build plan with argument restore (so that the command will be nuget restore); I've placed it right before my MSV Build task.
That was all I needed to get this to work properly according to the latest guidelines.
Nuget 1.4+ supports "Package restore" which embeds a call to an MsBuild task in the project file. When the packages are not available it will automatically restore them while building the project.
I'm sure this is old news, but my packages are in \packages. No amount of "dotnet restore" would work, until I explicitly mentioned the packages folder.
dotnet restore --packages .\packages
restored them!
VS2019. just in case it's version specific.
Every time I publish the application in ClickOnce I get get it to update the revision number by one. Is there a way to get this change automatically to change the version number in AssemblyInfo.cs file (all our error reporting looks at the Assembly Version)?
We use Team Foundation Server Team Build and have added a block to the TFSBuild.proj's AfterCompile target to trigger the ClickOnce publish with our preferred version number:
<MSBuild Projects="$(SolutionRoot)\MyProject\Myproject.csproj"
Properties="PublishDir=$(OutDir)\myProjectPublish\;
ApplicationVersion=$(PublishApplicationVersion);
Configuration=$(Configuration);Platform=$(Platform)"
Targets="Publish" />
The PublishApplicationVersion variable is generated by a custom MSBuild task to use the TFS Changeset number, but you could use your own custom task or an existing solution to get the version number from the AssemblyInfo file.
This could theoretically be done in your project file (which is just an MSBuild script anyway), but I'd recommend against deploying from a developer machine.
I'm sure other continuous integration (CI) solutions can handle this similarly.
Edit: Sorry, got your question backwards. Going from the ClickOnce version number to the AssemblyInfo file should be doable. I'm sure the MSBuild Community Tasks (link above) have a task for updating the AssemblyInfo file, so you'd just need a custom task to pull the version number from the ClickOnce configuration XML.
However, you may also consider changing your error reporting to include the ClickOnce publish version too:
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
Debug.WriteLine(System.Deployment.Application.ApplicationDeployment.
CurrentDeployment.CurrentVersion);
}
I implemented this recently using some custom tasks. An issue I found with implementing this with ClickOnce is that all your DLL files are updated. This causes the ClickOnce update to download all the application files every update. This bypasses on of the nice features of the ClickOnce deployment where only the modified files are re-downloaded in an update.
Just something to think about when implementing something like this with ClickOnce.
Steps:
Use external incrementing version number (if you leverage a continuous integration server like CruiseControl.NET, then it comes from the build label).
Use GlobalVersionInfo.cs (file link-referenced by all projects in your solution) to hold the current version and update it on the build with the AssemblyInfo task from the MSBuild Community tasks.
Script Mage command-line tool from the .NET SDK to update the ClickOnce manifest, using the same version (see the -v and -mv switches).
BTW, a nice bonus is that, whenever you automatically publish a newer ClickOnce deployment version via the integration script, if you also specify the minimal version to mage.exe (same as version), then every user will be updated automatically on the next application launch.
You'll probably need to create a piece of code that updates AssemblyInfo.cs according to the version number stored in the .csproj file. (The ClickOnce deploy version is stored inside an XML tag.)
You'd then change your .csproj file to run this bit of code when Publish|Release build is performed. The MSBuild folks have blogged about how to perform custom actions during certain build types; check the MSBuild team blog.