This document describes how to publish a nuget packages by creating a nuspec and then publishing it to a server.
In order to publish dlls as a nuget package, we need to perform these three steps:
- Create a nuspec;
- Pack the nuspec;
This document describes how to publish a nuget packages by creating a nuspec and then publishing it to a server.
In order to publish dlls as a nuget package, we need to perform these three steps:
| # This powershell script is aimed at batch replacing version numbers | |
| # in assembly info files. Provide the old version number that needs replacing | |
| # and the new version number to replace it with. Run the script | |
| # in the solution directory (e.g. the one that contains [ProjectName]\properties folders) | |
| Param([string]$oldVersion, [string]$newVersion) | |
| foreach($folder in Get-ChildItem -dir) { | |
| $assemblyInfoPath = "$folder\properties\AssemblyInfo.cs" | |
| Write-Host "Assembly info path: $assemblyInfoPath" | |
| if(Test-Path $assemblyInfoPath) { |
#Increasing version numbers in project.json or AssemblyInfo.cs using Powershell
As part of an automated deployment process, I needed to increase the minor version numbers stored in both project.json and AssemblyInfo.cs files. I achieved this with broadly similar powershell scripts.
## This script picks up a json file, locates the version property and
## increases the most minor version number by 1.I've recently been setting up multiple remote agents for Bamboo on the same machine to run as Windows service instances. Although there's information out there as to how this is achieved, I thought I'd document all the steps here for future reference.
Assumptions are that you have:
#Running NUnit3 tests in Go CD
Running NUnit3 tests under Go CD is easy enough using the console runner, but the outputted test results are not understood by Go, even when you mark them as a test artifact.
In order for them to be recoginized by Go, you need to output the test results xml file in the NUnit2 version.
This can be done by adding the following option to your command line call@
--result=TestResult.xml;format=nunit2
#Git command line cheat sheet
In a typical workflow, you might perform the following steps in approximately this order:
At the moment, I'm experimenting with interactions with a new database. I could very easily create the schema once and then take a backup of the database, restoring this backup every time I want to start again with a fresh copy.
However, it's a little more hassle free to leave the database in situ (especially because I want to use the same connection details each time) and just nuke all the data instead.
Removing all the data from a database is almost as easy as running a DELETE FROM for every table, except that you need to suspend constraints temporarily whilst you're doing so:
BitBucket and JIRA can be integrated such that JIRA issues display a development panel that allows you to create branches and pull requests and which can display commits that relate to that issue.
In order to setup this integration, a number of steps need to be followed that are widely documented, especially by Atlassian. I'm just noting down some of the perculiarities that helped me to get this setup.
In order for JIRA to remain up-to-date with BitBucket when things change in a repo, your repo needs to have two POST services configured. These are normally added automatically when you link a JIRA account with a BitBucket account, but if not:
#Useful Git Hooks
Below are a couple of simple git hooks that can be useful for controlling and formatting commits. These are generally re-hashes of other people's ideas, so I've credited these as appropriate.
Git Hooks
A git hook is a script that lives in your
.git/hooksdirectory. The scripts are invoked when certain events occur within your repo, such as make a commit or pushing changes. Hooks can be used to automate and augment basic actions within your repos.
##Include an issue number in your commit message
To amend your commit messages after they have been submitted, you'll need a commit-msg hook. I borrowed most of these ideas from @monkseal. This hook assumes that your issue numbers are formatted into you branch names in a way that you can extract using a regex.