4/14/2023 0 Comments Teamcity versions![]() The updated plugin system lets you write any sophisticated plugin and integrate it both in the experimental UI (code-named Sakura) and classic UI. This document explains the new way of the plugin development in TeamCity. It’s very simple.Initially, we shared our view on the TeamCity plugins and the motivation behind revising our plugin development approach in the dedicated blog post. If you’re running your own server, just download the plugin and set it up. As I mentioned initially, if you’ve got your project on CodeBetter, you already have this feature enabled. With a few simple build steps we have now fully automated packaging and publishing NuGet packages. Adding this option is as simple as selecting it from the main project configuration screen: This allows your build number, artifacts, packages and assemblies to all have the same version number. The AssemblyInfo Patcher is a new Build Feature added to TeamCity which temporarily patches all your projects AssemblyInfo.cs files to update the version number, and then reverts it back after the build is complete. AssemblyInfo PatcherĪlthough this step is optional I recommend you use it. TeamCity will follow NuGet’s convention and do this for you automatically. Note however that we did not have to specify an extra step to publish the sources to. If you want to publish to multiple sources, all you need to do is add another step. Here you can list each package individually or use wildcards. You need to provide your API key which is stored in a password protected field and finally indicate which packages you want published. If you have your own NuGet server then fill in the address in the Packages Sources field. By convention it uses as the destination to publish the package. As before, we need to add a Build Step and select NuGet Packages Publish. If you want to make this a release build, you can also do this by defining Configuration=Release in the Properties field.įinally I’ve specified the Build number of the package using the TeamCity variable %build.number% which auto increments on each build, and is also used by another feature of TeamCity new in 6.5 which is called the AssemblyPatcher, which I’ll show you as the last step. Additional command line parameters (if required) can be passed in the Additional Commandline arguments. This is also explained in David Ebbo’s post and it’s for publishing the sources to Symbolsource. I’ve also checked the option to Include Sources and Symbols. If you’re not familiar with this feature, check out David Ebbo’s post. The advantage to this is that we do not have to redefine information such as version number and copyright information in the spec file. Notice that in the Specification file, we can also provide a csproj file as opposed to a NuGet spec file. This will give us the following configuration screen:Īs you can see, the configuration is pretty straightforward. We create a new Build Step in our project and select NuGet Packages Pack. This step is for building the actual package. Step 1 simply builds the project by building the solution file. To give you a general idea of my build process, here’s the outline of the build steps: In my case, I want to create the package and publish it. ![]() Pulling NuGet packages required to build your project The plug-in offers three main operations: Select the version you want and click Install: TeamCity will read from the feed and display available versions to you in the dialog box. If the plug-in installed correctly, you should now have a new Tab called NuGet:Ĭlick on the “Install additional versions of the NuGet.exe Command Line”. Click on Administration | Server Configuration. The plug-in knows about the feed to it can grab the latest version of the command line tool directly. Once the server is running, and agents updated (automated procedure), you then need to tell TeamCity what NuGet version you want to use. ![]() Place the zip file into the plugins folder of your TeamCity installation and restart the server. If not, then grab the latest build from our public TeamCity server. If your project is running on TeamCity at, you can skip to Step 3, since it’s already installed and configured. After some initial trials and changes, I decided to setup YouTrackSharp to automate the publishing of the NuGet package. Eugene, who has been working on it, announced the availability of a first build a few weeks ago. Instead of delaying until the next release of TeamCity, this feature (like many), has been developed as a plug-in. A few months ago, Scott Hanselman gave a session at TechEd US were he showed some new features we were working on for TeamCity, in order to provide first class support for NuGet.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |