There’s only one issue, when I inject a micro ORM database (NPOCO) into where your IUserDataProvider is, it blows up, complaining something about ClaimPrincipal. I wasn’t even touching the claim principal, just calling the database and assign result to a local variable. Not sure why. You probably didn’t see it if you do database DI in the next layer from IUserDataProvider

I ended up changing the transformation class to something like this

public static IAppBuilder UseClaimsTransformation(this IAppBuilder app, string idType,
Func<string, Task<List>> transformation)

Thanks Erik, I really like the temp file idea, very clean.

I’ve toyed with the idea of generating a changelog of commits between releases, but it feels to me like it would have to be done at deploy time rather than build time – you could have multiple builds that get deployed (e.g. to test environments) between actual releases to production, and a change log would need to take into account all of them. It’s something I’ll try to follow up with a blog on.

Thanks for the comment!

Hi Sam,
the great thing about Serilog – and really the thrust of this article – is that it allows structured logging. You can embed your variables into the log message, which then become searchable. You can also add context which gets automatically added to every logged message.
ELMAH tends to be primarily used for catching and logging exceptions, but by adding a global exception handler, Serilog can do this too.

Some people use both, but I would stick with Serilog, it is definitely worth getting to know.

Thanks for your comment,

Darren

Thanks Nicholas, I appreciate you taking the time to comment. I have adjusted the code to dispose of the outer property, thankfully using middleware it’s easy to surround the call to the next piece of middleware with a using statement.

Also thanks for giving the community Serilog, it is an excellent product.

Darren

There’s one gotcha I think this approach might hit; LogContext needs to be “popped” again by disposing the object that’s returned from it, otherwise there’s the potential for space leaks (*not always).

E.g.:

var pushed = LogContext.PushProperty("Shop", siteAccessDetails.ShopName);
// Log things, then...
pushed.Dispose();

The * is because only the “outermost” property needs to be popped off, to remove any that were pushed on top of it, so you should be able to do this with only one IDisposable tracked.

There’s also a PushProperties() method that can accept multiple PropertyEnricher objects in a single call, which may simplify the “popping” aspect.

Cheers!

Then, in your build step, use the parameter: /p:OctoPackReleaseNotesFile=%system.teamcity.build.tempDir%\releasenotesfile_%teamcity.build.id%.txt

However, doing all this means that each package you deploy will have its own copy of the build steps, and the release itself won’t have the release notes (this is a drawback because the Overview page only shows the release-level release notes, not any package-level release notes, at least with more than one package as I can’t confirm what happens with one package).

Furthermore, see Generating a project change log with TeamCity and Powershell for a script that makes a much grander set of release notes, including all commits since the last build (or release? not sure). I souped it up to include the commit sha, with a link back to the source control web site’s commit page. I also plan to update the script to add links to anything that looks like a case reference back to my project management software. And finally, I plan to use the committer’s user name when TeamCity hasn’t yet been told which TeamCity user that committer actually is (do this in your user profile).

Last, if you accept building a new release every time you build, then add a TeamCity step, “OctopusDeploy: create release”, and in the additional command line arguments, put

--releasenotesfile="%system.teamcity.build.tempDir%\releasenotesfile_%teamcity.build.id%.txt"

This makes the Overview page in Octopus awesome!

Thanks for that comment, it’s great to hear that I have helped someone.

Darren

Hi Jay, thanks for the nice comment! To answer your questions:

1) I agree that is you’re working with a CSS pre-processor then ideally you don’t want to check in the generated CSS – they’re basically build artifacts. This is exactly what I ended up doing here, but annoyingly have since moved on from the project and forgot to write it up!

From memory, I referenced the generated CSS in my Views but didn’t include them in source control. I modified the csproj to add the generated CSS in the “BeforeBuild” Target section, but don’t believe there were any other changes. If it doesn’t work let me know and I’ll spend some time digging into it.

2) Yes, I’ve actually had the 4th part mostly written and sitting in my drafts for a while now, but just started a new contract which has eaten up my time. I promise I will finish it off and publish ASAP!