I stream on Twitch, on topics such as Chocolatey, Cake, and general Windows Automation topics. If you have any ideas for topics that you would like to see covered on one of these streams, then please feel to raise an issue in this repository, and I will do my best to cover them in a future streams.

On tonights stream, I was joined by Nils via the new Twitch Guest Star functionality, in order to continue working on the Cake.BuildSystems.Module.

Following on from last weeks stream, I noticed a couple things about the log grouping in GitHub Actions, that I wasn't really happy with. Digging into this on stream, we think that we need to go back to the ICakeEngine, in order to provide some more information, so that we can expose/use this information in the Module. For example, whether a task is skipped so that we can show, or not, the grouped information. And also for example whether a task actually has a TaskSetup/TaskTeardown. Without this information, we end up with empty log grouping in the GitHub Actions interface that we don't want.

With investigation of this area complete, we set about getting the Step Summary work done, so that we can see the Cake Task Summary in the GitHub Actions UI. After a little bit of tweaking, we were able to get this working, and actually took this for a spin in a test GitHub Actions workflow. The only thing that is left in this area, and something that I think we need to go back to Cake with again, is that we always want to see the output summary, even if there is a failure.

On tonights stream, we started doing some work on the Cake.BuildSystems.Module, which is part of the Cake-Contrib GitHub Organisation:

https://github.com/cake-contrib/Cake.BuildSystems.Module

On the stream, we were able to review a PR into this repository to add support for grouping of log messages in GitHub Actions (which was provided by Nils) and ship version 4.2.0.

Once this was done, we started looking at what is required to update the Module to use the latest version of Cake, since doing this provides the ability to write out to the step summary of a GitHub Actions workflow. We stubbed out an implementation of the ICakeReportPrinter, to take advantage of this, but this will need some more work, which I am hoping to continue next week.

On tonights stream we finished up the work on adding in a Spectre.Console alternative report writer for Cake output. This is configurable via a configuration option, and allows for the inclusion of a new summary column in the Cake summary to include the reason that as given task was skipped.

The completion of this work can be found here:

cake-build/cake#4056

And it actually shipped as part of Cake v3.0.0.

We closed out the stream by taking the new Twitch Guest Star feature for a spin. This allows you to easily bring guests onto your stream. This all seemed to be working, however, although we were able to "see" my guest (Stevie), we weren't able to hear him. Going to have to play with this, but looks really useful if we can figure it out!

On tonights stream, we continued to work on adding an alternative Report Printer for Cake using Spectre.Console. On the last stream, we worked on adding in a new column to the summary output, and on tonights stream, we extended the usage of Spectre.Console to also output the header section for each task, when executed.

There is still a little bit of work to be done in this implementation, but it feels like we are getting close, perhaps one more week, and we should have everything ready to ship.

On tonights stream, we started working on a new addition to Cake where we make use of Spectre.Console to provide an alternative report printer. The idea behind this is that I want to be able to include information about the reason that a given task has been skipped within the summary output from Cake, rather than having to scroll back up through the build output to find out why a task was skipped.

I have never really played with Spectre.Console before, but fortunately a coupe of folks (Patrik, Nils, and Kim) were on the stream who were able to provide guidance for how to get started.

I think this will make a great addition to Cake, and I am looking forward to getting this new feature shipped in next release of Cake.

On tonights stream, we were working on merging some PR's into the Cake.Transifex repository. There were a number of PR's from dependabot for updating the various dependencies that it has.

Getting this addin updated is part of the process for getting a new Cake 2.0.0 compatible release of Cake.Recipe ready. Still a fair bit of work to do here, but getting there.

Towards the end of the stream, there was a discussion about the different hosting options for Chocolatey packages, and also upcoming support for both NuGet v2 and v3 feeds.

On tonights stream, we continued working on Cake.AppVeyor, trying to get to a point where we can ship a new version with support for Cake 2.0.0. During the week, I worked through all the open Dependabot PR's, leaving on the actual work that needed to be completed.

During the stream, we merged a couple of PR's to address some small issues, as well as directly closing off some others issues.

With that done, we started working through a checklist of best practices for Cake Addins. This checklist was provided by Nils and Augusto, and we made sure that as many of those as possible were completed.

In the remaining time, we then went through and applied all of the StyleCop/EditorConfig suggestions to the code base. This will hopefully make the code more maintainable in the long run. We left some StyleCop warnings in place, and these were all to do with missing documentation, and my plan is to address those through the week, so we can ship a new release on the next stream.

Tonight was all about easing myself back into doing "stuff" in Open Source on my Twitch channel. Started out by reviewing and providing feedback on a PR into the Boxstarter repository. Then we switched over to reviewing/merging a PR into the Chocolatey repository which dealt with adding in a specific git file which excludes certain commits from the blame views in GitHub (this makes it much easier to reason about changes that go into a file, especially when a single change touches a lot of lines within a file).

After that, we then jumped over to the Cake repository a reviewed a couple of PR's from Mattias (devlead). We were able to get one of them merged, but the other needed some changes and we requested those in the PR, and will need to follow up again with another review, as well as taking the code for a spin to ensure that it works as expected.

Then we started looking at using the Cake.Twitter addin repository as a test bed for the recent changes that have been going into Cake.Recipe.

Very happy to be back doing "stuff", and excited about some of the upcoming work that I have in mind.

In the first stream in a LONG time, I took some time to ship a new 3.0.0 release of Cake.Recipe. This has been on my todo list for a while now, but after being inspired by Pascal who has been doing a lot of work recently on Cake.Issues, I thought it was time to get it out the door. Pascal has been using the alpha release of Cake.Recipe and hasn't run into any issues with using it, so that made it "easier" to actually get it shipped. The one thing that was left was testing it out, and Pascal had essentially already done this!

After getting 3.0.0 shipped, I almost immediately notied that the documentation within the nuspec file wasn't right, so we opted to quicky ship another 3.0.1 release to get this corrected.

With this work done, we are now in a position to start thinking about shipping a 4.0.0 release, with support for the 2.x version of Cake. In order for this to happen, there are a couple of addins that will need to be updated, so that will likely be the focus of upcoming streams.

On tonights stream, we worked on a LONG awaited project, well at least long awaited by me! This was the removal of UppercuT from the build process for the chocolatey/choco GitHub repository, replacing it with a Cake equivalent, in the form of the Chocolatey.Cake.Recipe project (why yes, the name of this project is AMAZING!). This project is now being used on a number of internal projects, and now is the time to start looking at bringing it to the Chocolatey build.

For the most part, we got things working, however, we left it with a couple things not quite working. Specifically, the creation of the Chocolatey packages isn't working since the assertion of the version number using GitVersion is resulting in a version number that is too long. And also the generated choco.exe isn't ILMerged with all the parts that it needs to be. This is due to the fact that the other internal projects use a different tool to do the ILMerge'ing, so a change will be needed to Chocolatey.Cake.Recipe to run the ILMerge tool.

So, still work to be done here, but getting very close to having this working!

On tonights stream, we started work on adding a new provider for GitReleaseManager to allow it to work with GitLab. This is something that I have looked into before, but never got to a point where it was working/ready. We set out by bringing in the NGitLab library, and trying to get it working for the "simple" thing of finding a milestone on the project. This is centre to how all things work in GitReleaseManager, so it made sense to start here.

We were able to get things working, but it all hinged on knowing ahead of time what the Project ID is, and it isn't clear how to get this.

I will need to reach out to the project maintainers to see what can be done here.

As a follow up, I did reach out to them, and this is what was said...

ubisoft/NGitLab#206

On tonights stream, we spent some time looking how we can change from StreamLabs OBS and go direct to OBS instead. I used to use OBS directly before, but something stopped working (I don't recall what), so I made the switch to Streamlabs OBS. After giving it a lot of thought, and reading up on some blogs, I decided to switch back.

The main idea of tonight was to try to get everything switched over, i.e. intros and outros, source, scenes, etc. but it quickly became apparent that this wasn't going to happen, so instead, we pivoted...

Since there were some folks on the stream that were also on Discord, we played with what was required to grab the audio output from Discord and bring it into the stream as an input. After a fair bit of playing around, and with some help from Stevie, we were able to get things working using the Blackhole 16ch application on my Mac. With this setup in place, we would be in a position to bring community folks from Discord onto our streams that we do as part of Chocolatey.

On tonights stream, we spent a bit of time updating the following PR:

cake-build/cake#3768

To address some feedback that came up in the review that was done. Tried to get the integration tests running, but think we are holding something wrong, as they don't seem to be running.

Then we spent some time looking at the Cake Visual Studio extension, to try to address some feedback that came in from the Visual Studio team about the new Visual Studio 2022 version of the extension. We can't find anything wrong with it though, so we might need to reach back out to the team to see what needs to be done.

Following on from last weeks stream where we attempted to ship a new version of GitReleaseManager, on tonight's stream we actually did ship it! Version 0.13.0 is now out, with support for .Net 6. This didn't go quite as smoothly as we would have liked, as the publishing of the Chocolatey package failed, and we needed to manually push out the nupkgs after that.

With that done, we spoke about what we would work on in the upcoming streams, and then provided access to the Cake.Sonar project to a community member who is working on updating the Cake.Sonar project.

This was my first stream of 2022, after taking some time off over the Christmas period to re-charge. I had intended on streaming the last couple of weeks, but due to the fact that I hadn't got everything running on my new MacBook Pro, I hadn't been able to.

Tonights stream was meant to be about getting a couple of things ready and then ship a new version of GitReleaseManager, with support for .Net 6, as this had been reported by a couple of community members. However...

Turns out that the build didn't work on my local machine due to a problem with the version of the T4 templating system that we are using not working on .Net 6. Updating the reference to that tool made things start working again.

We then moved onto merging in the dependabot updates that have been waiting for a while now. We started that process, but we actually ended up with more PR's than we started with, as starting the process of merging them in, triggered more updates to be found. We will need to continue this work another day...

On tonights stream, we picked up where we left off on the last stream (two weeks ago), and continued working on the VSCode Extension for Cake.

We spent some time removing all on the deprecated runners from the extension, as well as updating the docs around what the extension provides. After finishing up the core work, we spent some time testing all the functionality to ensure that everything is working as expected. Happy to say that at the end of the stream, everything was working, and we could start getting things ready to create a Pull Request.

The end result was the creation of this Pull Request:

cake-build/cake-vscode#592

On tonights stream, we were working on more closely integrating Cake.Bakery into the Cake Extension for Visual Studio Code.

Cake.Bakery works with Omnisharp to provide intellisense for Cake Scripts within Visual Studio Code, and currently, there is a specific step that needs to be completed to download and set this up when working within Visual Studio Code.

To make a more seamless integration, the suggestion was made that on initialisation of the extension, that it should automatically download Cake.Bakery and set it up with Omnisharp.

On the stream, we worked on ensuring that it would be possible to update the Omnisharp configuration file with the download Cake.Bakery binary location, and once it was clear that this was possible, we worked on downloading the Cake.Bakery nupkg into the extension folder. We then tested this to ensure it was all working, and happy to say that it was.

Then we did a bit of investigation into what other code could be removed from the extension. WIth the release of Cake 2.0.0, the Cake.CoreClr library is now not supported, so it makes sense to remove this from the extension. Still some work to complete here though. Will likely be the topic of the next stream.

On tonights stream, we went through the PR that had been created in the bakery repository here:

cake-build/bakery#138

This was an initial stab at updating bakery to use .NET 6.0. This PR was pulled down locally, and the feedback from the PR was addresses, and a local build attempted. This ran into a few problems, but these were worked through, and got to a point where the local build was fully working.

With the build complete, the Cake.Bakery.exe was tested with the latest 2.0.0-rc0001 release of Cake, and proven to work, and to provide intellisense for the new aliases, etc.

A new PR was created:

cake-build/bakery#143

since updating the existing PR wasn't possible, however, there were some issues with the GitHub Actions and AppVeyor build, but we ran out of time to get this completed.

Very happy with the progress that was made on the stream though!

On tonights stream, we worked on building the running/previewing of the Chocolatey documentation site on GitHub Codespaces, to also running it locally in a container.

We defined a .devcontainer folder to control how a container is created/run when running the site locally.

This was made possible using the Remote Development extension:

https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack

as well as having Docker Desktop installed:

https://www.docker.com/products/docker-desktop

With both of these things in place, we can run the documentation site both on GitHub Codespaces, as well as locally on a machine, without having to installing the specific requirements for the site to build/preview.

Very happy to say that this "just" worked, with very little effort.

On tonights stream, we were working on some PR's that I have recently opened. This first is a PR into chocolatey/choco:

chocolatey/choco#2390

and the second is one into chef/chef:

chef/chef#12159

These were opened earlier, and I had received some feedback on them, so it was time to action this feedback, and get the PR's updated.

Tonights stream was dedicated to reviewing various PR's across multiple projects, including:

• chocolatey/choco
• chocolatey/docs
• cake-contrib/Cake.AliaSql

Lots of work to be done here, as I seem to have missed some notifications :-(

On tonights stream, we worked on fixing a bug which has been reported in GitReleaseManager:

GitTools/GitReleaseManager#399

Once we got this fixed, we shipped a new version, 0.12.1:

https://github.com/GitTools/GitReleaseManager/releases/tag/0.12.1

Which has been pushed out to NuGet, and Chocolatey.

In the last stream, we shipped version 0.4.1 of the Cake Extension for Visual Studio, but we introduced a bug where the creation of new projects using the Project templates wouldn't work.

On tonights stream, we spent some time figuring out exactly what was going on with this, and at the end of the stream we were able to ship version 0.4.2. On testing, happy to say that this is now working as expected!

There is some follow up work required across all the Cake extension, namely Visual Studio, Visual Studio Code, and Rider, to ensure that the project templates that are in place are consistent across all of them. This will likely be the focus of another series of streams.

On tonights stream, we continued working on getting the Cake Extension for Visual Studio working on 2022. We were able to ship a new release of it, and we thought that things were working, but on further testing, we found that there was a slight problem when creating a project from the templates that we ship within the extension.

This problem is due to a coupling that exists between the items with the template and the GUID that the extension itself ships with. Some further investigation will be required here, as we ran out of time on the stream.

On tonights stream, we continued from where we left off in the last stream, working on getting the Cake Extension for Visual Studio working in the new Visual Studio 2022.

While we were able to get some things working, there are other parts that flat out not working. Most of the stream was spent looking into why the Cake menu structure within Visual Studio isn't working as expected.

Still lots of work to be done here, but it does feel like we are getting somewhere :-)

On tonights stream we were working on updating the Cake Extension for Visual Studio to work in the new Visual Studio 2022.

In order to get this to function, at the minute at least, you need to actually create two projects (so there are actually two extensions), and the recommendation is to use a shared project to contain the code that is shared between the two extension projects.

The end result is that we had "something" working, meaning that things compiled and we were able to run the new extension within the Visual Studio 2022 Preview. Still lots of work to be done here, but made some solid progress in this stream.

In a change of pace from the last few streams, I decided to work on something different, something that has been on my todo list for a while now... updating the documentation for GitVersion.

The current documentation site for GitVersion can be found here, however, it used to be hosted on https://readthedocs.org/. When we moved from there, we attempted to add some 301 redirects to the pages to direct folks to the new pages, however, we forgot a few things...

The default branch in the git repository changed from master to main, which meant that the docs build wasn't working anymore. On top of this, the new Wyam site was recently changed, so that pages were moved, however, the RedirectFrom attribute wasn't added to the frontmatter of the pages to make a soft redirect to new location. On top of this, Google has some memory of the previous pages in readthedocs site, so we need to add additional redirect to ensure that these links go to the right place.

We tackled all of these problems during the stream, and I believe we got a lot of things sorted out, but there is still some work to be done here.

The end result of this stream was this pull request.

On tonights stream, we continued working on the GLAA website. This time, we looked at the ability to edit the metadata for an album (i.e. the name, description, date visited, etc). This means that we can now go back and edit an album if we find that something isn't quite right about the information.

In order to allow this to work, we had to ensure that the markers.json file is updated with the potentially new long/lat information for an album. This ended up in a bit of duplicated code, that will need to be refactored, but from a purely functional point of view, the basic functionality of the site is now working, and can be populated with information about visits that have been made.

Continuing to work on the GLAA website, this time adding in some JavaScript to the page. This was to allow for the fetching of a markers.json file (populated with the lat/long details for the places that have been visited) to allow these markers to be displayed on a Google Maps widget.

We initially thought that we might be able to embed this information directly into the Razor Page to retrieve from there, but it was actually simpler to fetch this data, enumerate it, and add it to the Google Maps widget.

Now, on load of the main page, the markers.json file is fetched, and after a short animation, the contents of the markers.json file is shown on the map, and when you click on one of them, it takes you through to the album page with the photos.

Real progress being made here!

After last weeks shambles of a stream, we were able to figure out a few of the issues during the week that was preventing the site from working when published to Azure App Service. Turns out that the version of node on the build machine was wrong, and as a result the TypeScript transpiling (which is included in the template application by default) doesn't work. However, we don't actually have any TypeScript in the project just now, so removing this portion of the "magic" from the template, made things start to work.

With that part working, we started working on collecting some metadata about the albums that are being created, and storing this information in a data.json file within each album folder. This information can then be hydrated again, when browsing the album. This is a cheap version of a database for each album, but it also serves the purpose, so I don't think we will need anything much more complicated.

Well, this was an utter shambles :-)

Tonight I started working on a new pet project to create a photo album website which would be used to collect family trips that have been taken, including lat/long information that can be plotted on a Google Maps widget. This idea came about, as my eldest child showed an interest in helping getting this up and running.

So to get started, I took a look at this template from Mads Kristensen and the focus of tonights stream was meant to be around hooking up the bare template to an Azure Website, and to get it publishing there when a new commit is made to repository. This is where things started to go wrong...

Wasn't able to get deployments working properly using Azure DevOps, so switched to using GitHub Actions. This got us further, but there seems to be a problem with my Azure Portal, where I don't have my own subscription, but rather am tied to Mattias's one (something that will have to be investigated off stream). Finally got things deploying, but the site itself isn't working, even though it runs locally.

Tried to set up ApplicationInsights to get some clues as to what is going on, but that was a bit of a dead end as well. Think we were holding this wrong though!

In the end, ended the stream a little deflated, as we didn't get anything working as I had hoped, but will try again next week!

Well, this didn't quite go how I wanted it to, but hopefully the essence of what I was trying to achieve still comes across. I tried to have two cameras at the same time, one to show me, and the other to show the contents of the swag boxes that came in the post from GitHub. This didn't work, and ended up in all cameras stopping working, so that got abandoned quite quickly.

I was able to get through the contents of the swag box though, which was truly amazing, and I am very grateful to the folks at GitHub for sending this through!

On tonights stream, we switched back to working on doing some housekeeping of the Cake Addins that I "own" including:

• Cake.Coveralls
• Cake.Gitter
• Cake.Twitter

We worked through pulling in some dependabot PR's for these addins, as well as updating the icons and tags used by the addins, so that we could get some new releases pushed out. We were able to accomplish this for the first two addins above, but there was a failure on Cake.Twitter, so will need to go back and manually fix this.

Getting these addins updated is likely to be the focus of the next few streams, as I work through getting all my addins updated to the latest standards.

On tonights stream, we FINALLY shipped GitReleaseManager 0.12.0! The last release of GitReleaseManager was in March 2020, so it feels really good to finally ship this. There are some exciting new features in this release, including the ability to fully control how the release notes are generated vis Scriban templates. In order to ship this release, there were a few unit tests that we had to fix up, and work through to ensure that they all pass, but once that was done, we were able to push the button to release it!

Full release notes can be found here:

https://github.com/GitTools/GitReleaseManager/releases/tag/0.12.0

Created by GitReleaseManager of course! :-)

On tonights stream, we went through and tested all the functionality of GitReleaseManager, to ensure that everything is working as expected. We ran into an issue with how the uploading of assets was working (we put this down to a change in how OctoKit works) and we had to make a minor code change to get this to start working again. We also took steps to document (on paper currently) all the steps that we went through to test GitReleaseManager. It would be great to get these fully automated, but the slight problem there is that we need to test against a "live" repository, and things have to be set up in a particular way to get some tests to work, so this isn't something that is really simple to do. For now, having things documented is a great first step, and if/when possible, these should be moved to automated tests.

Happy to say that GitReleaseManager is now in a shippable state, and it should be possible to release 0.12.0.

Tonights stream was dedicated to debugging what is going on with GitReleaseManager. Last week we thought we got to a point where we could ship 0.12.0, however, when I went to release it, I noticed that there were some things that weren't working. For example, when attempting to create the release notes for 0.12.0 I noticed that it wasn't including the Breaking Changes issues, and also that we were missing mapping in AutoMapper and registrations in the IoC container, all of which meant that things weren't working.

Of the 12 commands that GitReleaseManager has, we were able to at least partially exercise 10 of them, so there is still some work to be done before we can ship things. The remaining commands that need to be tested are uploadasset (which we found a problem with right at the end of the stream) and the publish command.

On tonights stream, we worked on GitReleaseManager, specifically the last thing that was on the milestone for shipping 0.12.0, which was to include the ability to allow the creation of an empty release. That means that you no longer have to have a milestone with issues assigned to it, or an input file with release notes contained within it, you can simply create an arbitrary draft release. We quickly attempted to merge a final dependabot PR in as well, but there are issues with GitVersion when running the build, so we weren't able to get that pulled in.

On tonights stream, we spent some more time working on GitReleaseManager, trying to close off the last remaining issues in the 0.12.0 milestone. Specifically tonight, we worked on collecting together all the errors that can occur when generating a set of release notes, and output them all at the same time, rather than only the first one. This makes it much easier to see all the problems, rather than getting one error, fixing it, and then get another error. This has been a long standing request, so it is great to finally get this added.

Tonight we worked on GitReleaseManager and got a new GitHub Actions build up and running (Windows only for the minute). There is an issue running ApprovalTests on Linux and Mac, may need to reach out to Simon Cropp about this.

After that, we switched over to work on an issue to add a new option to the export command to skip the export of pre-release releases when exporting all release notes.

We finished the evening by having a look at the VSCode extension for GitHub Pull Requests and Issues to see what it can do. It looks like a really useful extension

On tonights stream, we continued where we left off last week and reviewed some remaining PR's into the Cake.Recipe project, and from there, we decided to switch to working on the GitReleaseManager project. There have been a number of great additions to that project, and it would be great to be able to get to a point where we can ship a new release. There were lots of dependabot PR's sitting waiting for review/merge, so we worked on doing some of those, and discussing what we need to do going forward.

Tonight we picked up where we left off last week, and fixed the remaining issues on the Cake.Recipe 2.2.1 milestone, and we were able to ship a new release.

With that done, we set about starting the upgrade process to get Cake.Recipe running with 1.1.0 of Cake. There was an open PR from AddinDiscoverer that updated most of the dependencies to this end, however, there was a breaking change in Cake which meant that part of the Cake.Recipe script had to be re-worked. This was the part of the script that worked on getting the Cake Arguments that had been passed in. With the switch to using Spectre.Console, this had changed.

There is an open issue on Cake which would provide what is required, but for now, we have to work with reflection to get at the information that we want.

After taking a night off last week, we were back to normal streaming tonight. Didn't have anything specifically planned for tonight, so just thought we would see where we end up.

We ended up shipping a new bug fix release of Cake.Bakery to try to fix an issue that was reported.

After that, we reviewed and discussed a PR into GitReleaseManager for removing the file header from all code files. We discussed that we might need to go back and review this change to add some form of file header back in, but for now, this change makes sense.

We also worked on some bug fixes for Cake.Recipe in preparation for a bug fix release to address a number of issues that have popped up while trying to use Cake.Recipe running on GitHub Actions.

Throughout the evening we also discussed topics for upcoming streams, and tried to start prioritising what we will be working on going forward.

Over the course of the last few streams, we have been focusing on the new 2.2.0 release of Cake.Recipe. This consisted of ensuring that Cake.Recipe could be used to do a complete publish of a Cake addin when running on AppVeyor, GitHub Actions and Azure Pipelines. With that work completed, it is time to start putting this new release into action, and on the stream tonight we made use of it to ship bug fix release of Cake.DotNetTool.Module and Cake.Gitter, as well as new release of Cake.Figlet and Cake.AppVeyor (both of which are now compiled against Cake 1.0.0).

Had a lot of fun on tonights stream, and it feels like it was very productive!

Building on the work from the last couple streams, the focus of tonight was to publish a Cake Addin completely, using Azure Pipelines. The addin in question was Cake.DotNetVersionDetector. We very nearly got to a point where we were able to complete the publishing of the addin. We ran into a small bug in Cake.Recipe in how it names the branches in its Azure Pipelines provider, but that should be a small change, which would allow the publishing of Cake.Recipe, ready for use in other addins. In addition, we found that there was a need for some additional documentation on the Cake.Recipe site, in order to make it clear how to use Cake.Recipe on Azure Pipelines.

The intention of tonights stream was to use the newly released version of GitVersion to publish the 0.2.0 release of Cake.StrongNameSigner on GitHub Actions, and to then move onto publishing another Cake Addin on Azure DevOps. Unfortunately, that didn't quite happen :-(

We found that when we tried to use the latest version of GitVersion to do the publishing of the addin, that it still wasn't working correctly. It was still asserting the wrong version number. The rest of the stream was spent trying to figure out why it wasn't working.

We attempted to add additional logging to try to figure out where the GitVersion execution was getting to, but that also didn't seem to work. The whole stream was a little frustrating.

On tonights stream we spent some time investigating why GitVersion fails to assert the correct semantic version number when building a tag on GitHub Actions. We were able to replicate this issue running locally on my machine by cloning the repository in the exact same way as GitHub Actions does, and setting the environment variables that GitHub actions uses.

Using this setup, we were able to run GitVersion whilst debugging in Visual Studio, and to figure out that there was a slight issue in how GitVersion was asserting the version number.

After making a small modification to the code base, we were able to get the correct version number asserted, with all the remaining unit tests passing. We created a Pull Request for this change, but we also need to create a unit test for this case, to make sure that there are no regressions.

We didn't have time to create the unit test on the stream, but will attempt to do this during the week, and get the PR updated.

On tonights stream, we started the process of updating the Cake.StrongNameSigner addin. There isn't anything currently "wrong" with this addin, however it is currently still using Cake.Recipe 1.0.0, and if updated, can taken advantage of things like enabling deterministic builds, etc.

In addition, the thought process is to use this addin as an example of how to fully execute Cake.Recipe on GitHub Actions as the primary CI system, rather than AppVeyor.

We got most things completed, adding issues to track everything that was changed, so that they can be used as a reminder for what needs to be done in other addins, but we didn't quite get to the point of releasing the new version.

Hopefully, this will be completed during this week.

Following on from the work that we did last week, on tonights stream we continued working on the Magic Chunks library. There was one remaining issue on the 2.1.0 milestone, which was to include XML documentation into the NuGet package.

This sounded like it should be really easy, however, it turned out there was a bit more work than expected. It turned out that there were some additional changes required to make things work on the different .NetStandard versions in the NuGet package, and to make sure that everything was copied to the correct location, ready for packaging.

We worked our way through this though, and in the end, everything seems to be working as expected. Going to be reaching out to Sergey this week, to see what the process for shipping a release is, and going to try to ship 2.1.0.

On tonights stream, we started working on a new project for our Monday evenings. I have been a long time user of the Magic Chunks library, which makes it super easy to update JSON, YAML, and XML files, using a consist API. There is also a Cake Addin for this library, which is one of the reasons that I started using it.

Over the years, this library has been a little neglected, so I reached out to the maintainer Sergey to see if he wanted some help to maintain it. He replied to say yes, and as a result, created a new Organisation so that I (as well as Pascal) could be added as collaborators.

We started working on some of the issues which had been assigned to the next milestone, which was mostly around updating some of the project files, getting things ready for shipping the release.

On tonights stream, we worked on a bug which had been raised on Cake.Recipe where when running on GitHub Actions, no messages are sent to Twitter/Gitter when a release happens.

We spent a little bit of time investigating the different environment variables that are populated when running on GitHub Actions, both for a "normal" build, and then a tagged build. We confirmed that these variables are different depending on the type of build is being run, and as a result, Cake.Recipe isn't able to establish the branch name associated with the build.

This is important, since the branch name is required in order to assert whether notifications to Twitter/Gitter are sent.

Once establishing that this was the case, we set about executing git directly to retrieve the branch name. After a few stumbles, we were able to get this to work how we wanted, although there is a requirement that the checkout GitHub Action along with running the unshallow command, to ensure that all branches are pulled into the clone of the repository on the GitHub Actions build runner.

With it confirmed as working, we committed this into the repository, and closed the issue. All in all, a successful stream!

On tonights stream, we shipped the 0.3.0 Version of the Cake Extension for Visual Studio.

We went through the process manually, and took notes about the items that could be automated, for example, adding GitReleaseManager into the mix for generating, publishing release notes on GitHub.

We also spoke through potential ideas about what to work on in future streams, and Adil volunteered himself to create some custom emotes for the stream :-D

After a quick recap of last weeks stream and what had happened in between, on tonights stream, we focused on the Visual Studio Extension for Cake. This included testing it out on both Visual Studio 2015 and 2017. After running into some issues with Visual Studio 2015 we decided to drop support for it. I feel that this was the right decision.

We then decided to try extending the current menu structure that is in place for downloading of other Cake bootstrappers. This turned out to be harder than I thought it was going to be, but we were joined on the stream by Matt Lacey (https://twitter.com/mrlacey) who was able to provide join guidance, including the installation of a Visual Studio Extension which helps with the creation of Visual Studio extensions (very meta).

After that didn't work, we spiked out the usage of the .NET Tool version of Cake, and this seems to work, so we should be able to move forward with it's usage, just need to tidy up the code a little bit.

Tonight was the first stream which used Streamlabs OBS, rather than OBS. Over the last week, I have had a few issues with OBS (it crashes every time I try to switch to a scene), so I setup Streamlabs OBS, and it seems to be working fine. Spent a little bit of time playing with the featured.chat tool, which I have setup. It will highlight any comment (or custom message) from the Twitch Chat in the centre of the stream. Will be great for moderators to let me know about something that I might have missed. Also I have setup alerts for when "something" happens on a stream, i.e. a raid, a cheer, etc. Been a long time coming, but got there in the end!

With the successful release of the Cake VSCode Extension during last week, it was time to switch gears a little bit, so it is time to start looking at the Visual Studio and Rider Extensions for Cake.

Tonights stream mainly focused on the Rider extension, since Nils has been doing some work on that recently to bring it up to a state that it is working for some of the functionality. We walked through the process of getting IntelliJ IDEA setup to a point where I was able to debug the extension, and to see it working in Rider. Nils has done a huge amount of work here, and it was great to see it working.

There was a lot of downloading of "stuff" in this stream, and a lot of waiting around while things got setup and configured, but the end result was that we were able to see the extension running, and being able to trigger a task from our Cake script to actually execute. Really looking forward to seeing what we can do with this extension, and bringing it up to par with where the Visual Studio Code extension is.

The Birthday Stream!

On tonights stream, which was the first time streaming on my birthday, we were working on the Cake Extension for Visual Studio Code. The aim of tonights stream was to ship the extension, as during the week (thanks in no small part to Nils) all functionality on the 1.0.0 milestone had been completed.

We set about doing some last minute testing, and we noticed one small problem. As part of checking whether a new version of the Cake .Net Tool is available, we made use of the dotnet tool search command. This command is only available when using .Net 5, and when testing on an older version (as used on my stream) this command doesn't exist. The functionality in the Cake Extension itself didn't break though, it just failed to correctly identify that there is a new version available.

On the stream, we decided that this wasn't enough in itself to prevent the release happening, and we went ahead to dry to ship it...

It didn't work :-(

We use the GItReleaseManager tool to manage the GitHub releases, and this tool no longer supports the combination of username/password for accessing GitHub, and instead needs a token in order to work. The Cake.VsCode.Recipe package hasn't yet been updated to use this token, and as a result, the publishing steps failed, so we weren't able to release the extension.

This will be released later this week, once a new version of Cake.VsCode.Recipe has shipped.

Continuing on the development of the Cake Extension for Visual Studio Code, on tonights stream we reviewed a PR from Nils to add some of the remaining required functionality. We merged this into the code base and then did some deeper dives into executing the extension to make sure that it works as expected. There were some issues raised out of this testing, but we are getting much closer to a point where we can ship the extension, ready for the 1.0.0 release of Cake.

On tonights stream we continued with the development of the Cake extensions for Visual Studio Code. There were a few changes along the way for other projects, since we took some time to review a PR into GitReleaseManager so that Kim could publish a new package for AHR. On top of that, we found a bug in the Cake.VsCode.Recipe which would prevent us from shipping the extension.

On tonights stream we continued with the development of the Cake extension for Visual Studio Code starting with reviewing a PR from Nils. After that, we spent some time digging into the code base to figure out exactly how the execution of the runTask and debugTask work, so that we can figure out how best to integrate these with the .Net Global Tool version of Cake.

The intention of tonights stream had been to continue to develop the Cake extension for Visual Studio Code however, the end result was that we merged from dependabot PR's, and then went round the houses a little bit trying to get the extension to work correctly. There is "something" in my environment that is making it not work as expected, and overall the experience was a little frustrating.

Along the way, we made some changes to the Cake resources repository to allow the downloading of bootstrappers for each Cake runners, however, in deleting the second branch (develop) it had the effect of closing all the open PR's into the repository, which I wasn't expecting. Apologies to anyone who was impacted by this!

The butterfly episode!

On tonights stream, we started working on the Cake extension for Visual Studio Code. The idea is to update this extension to make use of the .Net Global Tool version of Cake, and for all functionality to work out of the box with this runner. Ideally, it will be possible to configure the functionality to work with the other runners, but the extension should favour the .Net Global Tool.

Throughout this episode, there was a butterfly flying around me, and causing me to get distracted, so apologies for that!

https://twitter.com/gep13/status/1320850188685238274

Tonight, we spent the evening playing with GitHub Codespaces. I have been given access to the private beta of this feature, so I thought I would take it for a spin.

The idea would be that I could utilise Codespaces for the various Cake addins that I work on, to allow running some integration tests, with all the tools needed to do the testing already installed, etc.

However, the end result was that things didn't seem to work really well. Sometimes the Codespace would be created, other times, there was a generic error shown that didn't really help. It could certainly be that I was holding it wrong, but the upshot was that we didn't get quite as much done as I had hoped.

Codespaces has a LOT of potential, and I do think it will be a common workflow that I start using across my OSS development, I just think that there are some teething problems that need to be addressed first.

On tonights stream, we started investigating an issue (cake-contrib/Cake.Recipe#695) that was reported on the Cake.Recipe (https://github.com/cake-contrib/Cake.Recipe) project.

The upshot of this was that the length of the names for files that are being extracted from the NuGet package are too long. As a result, when the build runs, necessary files can't be found, and therefore can't be run. We spent the evening debugging into this, and eventually figured out what was going on.

Initially we thought that something had changed with the NuGet package and that the application names had changed, but this wasn't the case.

This will be documented as a known issue on the site.

Tonights stream was a little bit of a mixed bag of things. We started looking at some issues that were brought up with when using Cake.Recipe, specifically when using GitVersion. We figured out one of the issues, and we made a change into Cake.Recipe to fix it. The second issue we need to follow up with Pascal about.

Then we looked at some PR's that have come into Cake.Recipe and we got these merged in.

Finally, we looked at setting up a Circle CI build for a Chocolatey workshop that Manfred Wallner is giving on Chocolatey OSS. This involved setting up a build which creates a base image using Packer, and then terraform to instantiate multiple versions on the computer which can then be used in the workshop. We got the basics of this working, but we need some environment variables configured which would allow the deployment of the images into Azure.

On tonights stream, which was stream 100 (quite a milestone) I was joined by Maurice Kevenaar, who was showing us how to install/setup/use his new chocolatey-diff tool:

https://github.com/chocolatey-community/chocolatey-diff

This is a PowerShell module, which makes it possible to quickly identify the differences between two package versions for a Chocolatey Package. This is especially useful for moderators who are reviewing packages in the moderation queue.

We showed how this can be used on both Windows and Mac.

There were some issues with Twitch this evening which is a little unfortunate, but we made the most of it. Maurice and I were able to continue chatting even though the connection to Twitch was failing.

On tonights stream, we worked on fixing the Cake.Twitter addin, where we (and by that I mean I) inadvertently broke the environment variables used to publish the tweets during the build. We fixed this on stream, and verified that things were now working.

After this, we worked on some more elements related to getting ready for the Cake.Recipe v2.0.0 release.

On tonights stream, we looked at the steps that need to be completed in order to move a repository that is using Cake.Recipe 1.x onto Cake.Recipe 2.x. We used the Cake.DotNetVersionDetector as the example repository, and we worked on converting it over.

The end result of tonights stream was this PR, and we updated this GitHub issue.

with the steps that are necessary to do the conversion. We also started looking into adding some GitHub actions into the repository, based on the work that Kim has been doing lately. It will be great to start adding in some of these workflows, especially for the triggering of release notes generation, and documentation publishing.

On tonights stream, we focused on trying to bring some consistency on the GitReleaseManager code base in the form of adding/updating the EditorConfig and StyleCop settings for the project. Drawing inspiration from some work that has been done by Patrik Svensson, we become by updating the EditorConfig files for the project, and starting to work through some of the warnings/errors that were being generated.

The culmination of this work went into this PR.

There is still some work to do here, but it is a great start!

On tonights stream, we switched focus to work on GitReleaseManager.

We reviewed a PR which adds in the ability to use Dependency Injection to control how the internals of the code base works. This was a PR that came from a community member, and it was great to finally get this merged in.

The same community member also created an issue raising some other issues about the code base, and during the remainder of the stream, we worked on implementing some of those changes. There is still some more work to be done for the issue that was raised, but we were able to get through a fair chunk of it.

On tonights stream, after a little bit of a false start, we worked on the AppVeyor build for Boxstarter. For a little while now, this has been failing, for no apparent reason. Nothing has changed from a build point of view, the psake script is exactly the same, and the *.sln and *.proj files haven't changed.

Testing locally, it appeared that the same problem was happening as on AppVeyor. That was a good sign in terms of figuring out what was going on.

We started out by trying to address some of the direct build errors with regard to missing WebApplication targets. Getting past that, we looked at the other errors which spoke about missing platform property for MSBuild. This was indeed the case, so we addressed those problems.

The final error was related to NuGet targets, which we couldn't find a solution for. Digging into NuGet, we checked if there had been new releases lately, and turns out there had been, around the time the build started to fail. Checking, the psake build doesn't pin to a specific version of NuGet, so we pinned to an earlier version, and magically, things started working. We didn't spend any time digging into why it fails with the newer version of NuGet and instead, moved on.

All changes were checked in, and pushed up to github.com.

On tonights stream, we worked on publishing a new 1.0.0 release of the Cake Extension for Azure DevOps. We wanted to do this due to the fact that we know were are going to make a breaking change to the extension, and wanted to ship a 1.0.0 release so that folks can pin to a specific version before the breaking changes.

With that done, we then reviewed the PR from Louis Fischer, which introduces the breaking changes, namely to convert from using PowerShell execution to Node execution. This will mean that the Cake Extension can be used on any build agent operating system, rather than just Windows. In addition, the Extension switches to using the .Net Global Tool for Cake, rather than the .Net Framework runner.

We debated about whether we "should" ship version 2.0.0 of the Extension, but in the end, we decided that we should, and happy to say that everything appears to be working :-)

On tonights stream, we spend some time trying to get Cake.Recipe to run on .Net Core. This is now possible due to the fact that Cake.Issues.Recipe has been updated to use the new version of Cake.Issues.Reporting.Generic, which in turn now makes use of a new version of Gazorator, which has been updated to work with .Net Standard.

Now that all of these pieces have been updated, we updated Cake.Recipe to use the new version of Cake.Issues.Recipe, and we were able to get it running under .Net Core :-) This meant pulling in a new version of Cake itself, namely 0.38.4, which meant there were a few necessary changes to remove some obsoleted usages. We took this for a spin on the GitReleaseManager project, and happily it all works.

There will likely be some fall out from this, and things that we need to further test, but this was a big step forward!

Spent the first part of tonights stream looking at a couple of tools that I have been meaning to play with. The first being RepoZ and the second being RepositoryCleaner. Both of these can be installed from Chocolatey. The first is a really useful little tool for easily finding and navigating repositories on your machine, and when on Windows, adding the git status information to the Windows Explorer shell - amazing! The repository cleaner tool actually kept crashing when I tried to run it, so I will need to speak to the author about that one.

Later on the stream, we also played with Fusion++, from the same author who created RepoZ, which is another great tool!

Getting down to some coding, we released a new version of Gazorator, which addresses a NRE which was seeing when trying to run tests. We got this shipped, only to find that there is another NRE later in the code base. We got a PR up to address this, but didn't release a new package, as we continued with the testing.

Something still isn't right when running Cake.Issues.Reporting.Generic via .Net Framework. Everything works when running via the .Net Global Tool for Cake, but not via Cake.exe. I thought it might be an assembly loading error, which is why we installed Fusion++ to see if it could help, but no joy.

Going to have to continue digging into this...

On tonights stream, we picked up where we left off last week, continuing to look into integrating Gazorator into the Cake.Issues.Reporting.Generic addin. Last week we completed the work of changes required to get things compiling within the addin, but things weren't working, both in terms of the Unit Tests, but also the generated reports.

During the week, Pascal had been able to do some work on the PR that was raised into Cake.Issues.Reporting.Generic, so we continued digging. We found at least one issue with Gazorator, and we worked to get a PR created which would make things work:

bjorkstromm/gazorator#12

Then we figured out why some reports weren't generating properly, and were able to make some small adjustments to the report templates to get things working. It basically boiled down to a missing using statement in the template. Previously, that using statement must have been included by default within RazorEngine, but not in Gazorator. The decision was made to be more explicit within the report template, and to ensure that the using statement is included.

On tonights stream, I was joined by Pascal Berger to talk about Cake.Issues.Recipe. This is being used within Cake.Recipe, and helps to collate and report of different issues which are found during the build.

The reason that we wanted to work on this was due to the fact that one of the Cake.Issues addins, Cake.Issues.Reportin.Generic, currently doesn't support .Net Core. We are currently working towards .Net Core support for Cake.Recipe, and this addin is one of the last things on the list to get us there.

We spent a little bit of time discussing what Cake.Issues and Cake.Issues.Recipe are, and then discussed what is needed to make it work. Basically, it is the Razor templating support that is the roadblock. Martin Björkström, is the maintainer of Gazorator which is a Razer templating engine, which does support .Net Core. We looked at what was required to pull in this library, rather than what is currently being used.

We weren't able to get this working completely, but we did make some good steps in the right direction.

On tonights stream we looked at what is required to create a fully deterministic build:

https://github.com/clairernovotny/DeterministicBuilds

Ultimately, this is something that I want to support within Cake.Recipe, but I have been running into issues with getting it to work. Specifically, there have been issues with trying to fully enable SourceLink through Coverlet. I reached out to the maintainers of Coverlet, and they mentioned a potential fix, which we were able to confirm as a workaround.

Had a lot of fun on this stream, working through what needs to be done to allow debugging into a Cake Addin when debugging a Cake Script in VSCode.

After jumping through a couple of hoops, we were able to get everything working! We enabled SourceLink on the Cake.FileHelpers addin (which had been contributed via an automated PR) and published a new version of Cake.FileHelpers. With that done, we created a some test Cake script to try debugging into the code of a method that this addin exposes. To start with, this wasn't working, but after a suggestion from Martin (@mholo65) we altered the launch.json file we were using to change how OmniSharp was setting up the debugging. With this done, it all "just" worked!

The end result of this stream was a couple of issues being created to improve the experience even more:

• cake-build/cake#2820
• cake-build/cake-vscode#376

Also, there will be some work to go through and suggest this addition to all Cake-Contrib Addins, so that everyone can take advantage of this!

Thanks to everyone who helped getting this to work!

On tonight's stream, we worked on a new feature that is getting added to Chocolatey GUI, the ability to have the concept of global settings, in addition to user settings.

chocolatey/ChocolateyGUI#602

This comes from a problem where when trying to set these settings, which are user by default, using a CM system like Chef, Puppet, etc, that these values are never set properly, and they cause problems.

Having the ability to set them at the machine level means that provisioning these settings will work, and still allow the user to override them, if they choose to.

The work on tonights stream resulted in this PR getting created:

chocolatey/ChocolateyGUI#781

On tonight's stream, we worked on shipping a new version of the Azure DevOps extension for Chocolatey. Based on some work that was done by David Gardiner, the extension now includes a new task for installing Chocolatey onto a build agent. This work had already been pulled into the repository, so we worked to actually get it published.

There were a couple of hiccups as we worked to make sure we had the right token to publish the extension, and we finally got it published.

Once published, and after doing some testing, we found that a bug had been introduced, so we worked on getting that fixed, and we ended up publishing another, unplanned, extension version. After some more testing, things seem to be working, but we will need to follow up with David, and the Chocolatey team, about some remaining questions. Once those are ironed out, we plan to ship a 1.0.0 version of the extension, so that folks can pin to a specific version of the task.

On tonights stream I was joined by Chocolatey Founder Rob Reynolds.

To give a preview of the upcoming release of Chocolatey Central Management Deployments.

This is a new feature in the 0.2.0 version of Chocolatey Central Management which allows you to manage both simple and complex scenarios with ease across your environment.

You can find more information about this in the blog post

Apologies for the quality of the stream on Twitch tonight. It would appear that there were some issues with Twitch, and I was seeing a lot of dropped frames in OBS. This fixed itself after a while, but was still a little annoying during the stream.

We started tonight reviewing a PR from Maurice into Chocolatey GUI.

We got this reviewed and merged into the code base. We discussed a related change, which resulted in this issue being created. . Then we went on to look at the rebase GitHub action.

This is something which I have been looking to get working on some of my repositories for a long time, but nothing has ever worked the way that I expected it to. This GitHub Action shows a lot of promise though, and we spent some time trying to get it working on this repository

We got a "simple" PR rebased successfully using it. By simple, we mean a PR from the same base repository. Then we set our targets on getting a PR that comes from a fork working. In the end we were able to get this working, but there were some security concerns around it's usage, so we backed out those changes. Need to come back to look at this again, as this is something that I would love to see working, as it would save so much time and effort!

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

To add new aliases for GitReleaseManager

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

This stream was broken up into two parts due to a technical problem

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes for this stream.

Working on Cake.SemVer.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

Apologies, I didn't record any notes for this stream.

Apologies, I didn't record any notes from this stream.

On tonights stream, I was joined by Andrew Nesbitt talking through the process of setting up an application within GitHub Marketplace.

Apologies, I was lazy and haven't got any notes about what was done within this stream. In general, we were working at bringing in StyleCop into the project.

First stream after a short break.

I have been lazy, and happened captured notes for this stream.

In today's lunch time stream, I was continuing to work on the secret project called devgep. I started out the stream thinking that I was going to be creating an ASP.NET WEB API project which was going to be the access point for the Azure Functions and Azure Table Storage that makes up the backend of the service that we are creating.

However, after a short discussion with Mattias who was on the stream, it was agreed that this wasn't required. Instead, creating another Azure Function, is all that would be required. I set about trying to do this, which meant that I had to install the Azure Workload for Visual Studio since I didn't have that installed, but once that was in place, everything was setup ready to start working with it, and I am happy to say that everything just worked.

It was AMAZING!

https://clips.twitch.tv/BrainyInspiringTurnipUWot

In part 5 of the series on the secret project that is known as "devgep" we worked on getting the Cake Build for the project finished off, and then we started working on removing the sections of the website that we decided that weren't required, i.e. the ability to change a password, use 2FA, etc.

None of these things will be required, since we are using an external authentication provider, in the form of GitHub, so having this ability on our site, isn't required. With those changes made, we were able to re-enable DupFinder and InspectCode, and got them passing as part of the overall build as well.

In part 4 of the devgep secret project series, we reviewed what has been created in the project to date, and then started looking at creating a Cake build script that could be used to build the project.

We started looking at how we could use the Cake.Recipe project to do the build, as that would mean that a lot of the build process would already be completed. This seemed to be going well, with things like DupFinder and InspectCode working, however, it then became clear that Cake.Recipe wasn't going to work.

Kim pointed out that there was an existing issue on the Cake.Recipe Issue list to split out into a new recipe specifically to build websites.

Going forward, I think that this would be a good idea, and we may look into doing that. For now, we will create a build specifically for this project, and look into splitting this into a recipe later.

Tonights stream was Part 3 in the series of working on the secret project that is code-named "devgep". Here we started working on creating a new "Subscriptions" area of the site, and made sure that this section was secure, and only accessible to logged in users of the site. This was required based on directly trying to access the URL, and also by providing a link to the section (which was only visible when logged in). This proved to be a little bit harder than expected, as some additional configuration was required in the Startup.cs class, to ensure that the redirect to the login page directed to the correct page. With using a custom Authentication provider as well as persistence store, the default URL was being used, and we had to figure out how to override it.

With the help of the people in the chat room, we were able to figure this out.

We also looked at how we could add StyleCop into the build process, to ensure that there is some consistency and maintainability of the code base.

In todays lunchtime stream, we revisited what was required in order to get the Azure Local Storage Persistence of our ASP.NET MVC Users working. On Monday nights stream, we had been able to get the creation of the database working, but the actual creation of the users wasn't working due to the pages on the site itself not working. After a conversation with the creator of the provider I was able to figure out what was required by scaffolding out the views/controllers using a tool that is shipped by Microsoft. With this done, the pages started to work, and we were able to correctly register new users on the site, which were authenticated via GitHub.

In this first stream about a new secret project called "devgep", we started looking at how to create a new ASP.NET MVC website using the dotnet cli.

With the site created, we then added in the ability to authenticate to the site using GitHub, which actually turned out to be really simple. With that done, we turned our attention to how we can persist the user information into Azure Table Storage, rather than the default Sqlite Database.

This turned out to be harder than expected, as we spent a long time trying to get the Azure Table Storage Emulator installed and working correctly. Once we finally got it installed, we were able to create the tables that are required to persist the user information, but then the pages on the website itself to register a new user stopped working. More investigation will be required to get this to work.

In todays lunch time stream, we took a look at the new Yeoman Generator which has been created by Kim Nordmo, specifically to help with the creation of a new project structure when creating an addin for Cake. This Yeoman Generator can be found here.

During the stream, we started from the very beginning, getting Yeoman installed, installing the generator, and then looking at what the generator creates for us. There were a couple of hiccups during the walkthrough, but Kim was on hand during the stream to explain what was going on, and also a new version of the generator was released during the stream what corrected some of the issues that were shown.

Huge thanks to Kim for creating this generator, as I think it will be of great help to the Cake Community!

In tonights stream, I took at stab at writing some Ruby code, to try to improve the Chocolatey support in the Chef client. This came about about creating a previous Pull Request to Chef to add support for enabling/disabling features while I was at Chef Conf in Seattle.

The first part of the stream was spent trying to get a Chef environment up and running so that things could be tested. There seems to be an issue with the latest Chef Client that was causing problems for my setup. Installing a previous version of the Chef client resulted in things working.

This all culminated in a Pull Request being submitted to the Chef GitHub repository here

In todays lunch time stream, we continued working on the feedback that was received from the PR that was created for a new Export Command for Chocolatey.

Following a quick Google, I found this Stack Overflow answer, which suggested a convention based way to allow control over whether or not a property in a class is serialized or not. We put that to the test during this stream, and it worked!

The PR in question is here.

Following on from my stream where I paired with Rob Reynolds:

In today's lunch time stream, I started working on the feedback that was received from the Pull Request review. We were able to get to a point where some feedback was addressed, but there was some work left to figure out how to correctly serialize the list of packages in the required format.

The PR in question is here.

In tonights stream, I was joined by Chocolatey Founder Rob Reynolds, to discuss the Pull Request and Code Review strategy that is used on the Chocolatey Open Source Project on GitHub. It focused on discussing two PR's that were sent into the project, one of which was merged, and the other was updated with some feedback.

This live stream was really a continuation of the work that was done in a 2-part stream series.

Part 1: https://youtu.be/jFozwL8qizU

Part 2: https://youtu.be/ppc3eZtILVM

Where we built a new Chocolatey Export command for exporting a list of the currently installed packages on a machine into a packages.config file.

During this live stream, there was a hard stop due to a network failure on my side. As a result, the stream is split into two videos.

In this lunch time stream (which is going to be the last one on this topic), we looked at updating Cake.Chocolatey.Module to use the latest version of Cake.

In the end a new release, 0.6.0, of Cake.Chocolatey.Module was released:

https://www.nuget.org/packages/Cake.Chocolatey.Module/

During the stream, there was a discussion about Git Flow, and some of the specifics of now it works, as this was discussed offline between myself and Kim.

This stream also saw me use the Co-Authored ability in GitHub on some commits, so that people who helped in the stream can be attributed with their help. More information on this here:

https://help.github.com/en/articles/creating-a-commit-with-multiple-authors

The stream this evening focused on the concept of Chocolatey Extension and Template packages. This was a topic that was requested by one of my regular viewers, and in this stream, I walked through what these types of packages are, and how they can be useful to Chocolatey Package Maintainers.

Towards the end of the stream, I attempted to create a template package specifically for creating an extension package, however, we ran into a few issues when trying to do this. I have collected a number of issues that need to be investigated in Chocolatey to see if this package can be completed.

Documentation about creating Extension Packages can be found here and for creating Template Packages here.

In this lunch time stream, we looked at updating Cake.Coveralls to use the latest released version of Cake, 0.33.0.

This is required because there were potentially breaking changes made in Cake in this release, and as such, it is preferred that Cake Addin Maintainers update their references.

In the end a new release, 0.10.0, of Cake.Coveralls was released:

https://www.nuget.org/packages/Cake.Coveralls/0.10.0

This video really serves as an example of how to upgrade/pin to the newly released version of Cake.Recipe, 1.0.0, as well.

In tonights stream, I was joined again by Mattias Karlsson and we continued speaking about the current Cake Build Website Infrastructure, and how we are going to be changing it.

We picked up where we left off from the previous stream:

http://www.youtube.com/watch?v=6OtNIpIOfRU

And ended up with a website deployment that has gone from over 30 minutes to complete, to one that takes just over 7 minutes to complete, and that includes deployment to 3 Azure App Services.

All the work was done in the open, and can be seen in these commits:

https://github.com/cake-build/website/commit/13311f124033744010ea66f3ebef488de68ea240 https://github.com/cake-build/website/commit/83862e07ab31fed03d004a0bbdd09d194b0b611a https://github.com/cake-build/website/commit/4b371cf7f91c354f2164b9236df755ecc437f9ed

In this lunch time stream, we looked at updating some Cake Addins (Cake.Gitter and Cake.VsCode to use the latest released version of Cake, 0.33.0. This is required because there were potentially breaking changes made in Cake in this release, and as such, it is preferred that Cake Addin Maintainers update their references.

In the end new releases, both 0.11.0, Cake.Gitter and Cake.VsCode were released:

https://www.nuget.org/packages/Cake.Gitter/0.11.0 https://www.nuget.org/packages/Cake.VsCode/0.11.0

The focus of tonights stream was to try to get Cake.Recipe to a point where a stable release could be published. Cake.Recipe has been in beta for a LONG time now, and going forward, it will require a number of breaking changes. While it has been in beta for a long time, it is actually relatively stable, as such, the decision was taken to get to a 1.0.0 release, and then break things going forward. In this stream, we triaged the issues that were associated with the next stream, and either bumped them to the next release, or completed the work necessary to get it to work.

In this lunch time stream, we looked at updating a Cake Addin (Cake.Ember) to use the latest released version of Cake, 0.33.0. This is required because there were potentially breaking changes made in Cake in this release, and as such, it is preferred that Cake Addin Maintainers update their references.

There were a couple of hiccups along the way:

• Live Stream VM is still rebooting due to license expiration
• JetBrains DupFinder was failing to run due to lack of Visual Studio installation
• Intermittent AppVeyor build failure

But we got there in the end and a new 0.4.0 release of Cake.Ember was released here:

https://www.nuget.org/packages/Cake.Ember/0.4.0

In tonights stream, I was joined by Mattias Karlsson and we spoke about the current Cake Build Website Infrastructure, and how we are going to be changing it.

The idea in this stream was to move to a Zip Deployment of the website, which is generated using Wyam, instead of deploying the files directly. The intention was to shave many minutes off the overall deployment time of the website. However, the stream was plagued with a number of issues...

• Mattias's Skype connection kept dropping out
• My Live Streaming VM's kept rebooting due to not having a valid product key
• Azure and Azure DevOps permissions were fighting our ability to carry out some actions

The end result was that we didn't quite get to a point where we were successfully deploying the site via Azure Pipelines, but I think we have all the component parts in place, we just need to work through a few remaining issues.

In this lunch time stream, we looked at an outstanding issue in the Cake Build Visual Studio Code Extension:

cake-build/cake-vscode#93

Which causes the file that is being added to, to be reformatted, stripping all whitespace. This is far from ideal.

Stepping through the code, it was refactored to remove the usage of a file stream which reads and writes all lines in the file being edited, and changed it to simply add/update the current file that is open.

Decisions had to be made regarding removing some functionality, as the way that things were implemented, meant that some functionality would be lost.

In this stream, we walked through the process of doing a release of the Cake Open Source Project. This resulted in version 0.33.0 of Cake being released to NuGet, Chocolatey and Homebrew. The only thing that was left unfinished was a release blog post detailing what was included in the release.

This was very much a behind the scenes look at how the Cake Team does the release process, showing the tools and techniques that are included. We know that this isn't perfect, and likely some additional things can be automated, but at the very least, all the steps are documented, and can be followed by anyone on the team.

In this stream, we looked at what process should be followed when you find a package on Chocolatey.org that is in need to maintenance. This included a discussion about how to reach out to the current maintainer(s) of a package, how to request help on a package, and also what you as an individual can do to try to help fix/update a package. This video ended up with trying to create a PR to fix the Octave package, which currently doesn't work correctly. We were able to successfully walkthrough the process of updating the package, however, when it came to testing the package, we found that there was an issue. This looks like an upstream issue, which is preventing the Chocolatey package from working correctly.

Even though this wasn't successful, we were able to show the entire process that should be followed when attempting to get a package on Chocolatey.org updated.

In this stream, we looked into the process of converting a manually updated Chocolatey Package into one which is automatically automated. This was done using the AU PowerShell Module:

https://github.com/majkinetor/au

I was joined on this stream by Maurice Kevenaar who is a Community Chocolatey Package Maintainer, with 81 packages to his name. He currently uses the AU system, and helped walk through what is required to convert to using AU for this package.

This entailed creating a update.ps1 file, with the specific functions that are required to make AU work. The end result of this stream can be seen here:

https://github.com/gep13/inedo-chocolatey-packages/commit/dfe8716c9e51bbe457125756b789b498d808699c

Some examples repositories that are using AU can be found here:

• https://github.com/chocolatey/chocolatey-coreteampackages
• https://github.com/mkevenaar/chocolatey-packages
• https://github.com/AdmiringWorm/chocolatey-packages
• https://github.com/pauby/ChocoPackages

This was the second of my lunch time streams, where we were once again focusing on the new VSCode Extension that we are creating.

This time, we set up mergify.io on the repository, as well as merged a PR that was created by dependabot. This PR required some manual intervention, since the new type definitions for node meant that some additional guard's were required in the code base.

With those things done, we started looking at the uploading of the files into Azure Storage. We started looking at how the Azure Storage extension is doing this, and tested out it's functionality using a newly created Azure Storage Account. This all worked, and we should be able to lift the code in quite easily into the extension. There will be some work on my Azure account required, as right now, the storage account I am using is a classic account, which isn't really supported any longer.

In a change from the last few streams, this stream focused on a new topic. In this stream, we delved into running PoshBot:

https://github.com/poshbotio/PoshBot

and how to go about creating a new Plugin for it. We got a new "soon" plugin up and running, and the source code is published here:

https://github.com/gep13/poshbot.soon

We also showed off the new Backend for PoshBot to be able to use the Gitter messaging system. The source code for that can be found here:

https://github.com/gep13/PoshBot.Gitter.Backend

Really, all that is left is to publish these modules to the PowerShell Gallery. This was discussed in the stream, and Brandon Olin, the creator of PoshBot, explained how this can be done.

This was the first of a new time slot for streaming, which is going to be during my lunch hour every Friday. This is going to be a shorter stream, as it is sandboxed to only a maximum of 1 hour.

In this stream, we successfully broke the build for the new VSCode Extension that we are creating, and tried (to no avail) to figure out what was causing it to fail. We also looked at adding some additional build related files to help with the overall build process, and spoke about what needs to happen in the final part of the extension, i.e. uploading the files to Azure Storage.

Update: Turns out it was some sort of transient error. Builds are now working correctly.

In this stream, we continued working on a new VSCode Extension for working with the contents of the clipboard, and allowing this to be uploaded to Azure blob storage, ready for pasting into a markdown file, for creating blog posts, documentation, etc.

We started by reviewing a PR from Kim Nordmo which implements the usage of InversifyJS within the extension:

https://github.com/inversify/InversifyJS

This was a great PR, which I have since implemented in two of my other VSCode extensions. With this merged, we then started looking at implementing dependabot on the repository, as well as creating a default set of labels for the repository.

Then, we starting looking into how to grab the clipboard contents on each operating system. This was done by using the same functions that are used in this extension:

https://github.com/mushanshitiancai/vscode-paste-image

Which makes use of PowerShell, ActionScript and bash, to grab the contents of the clipboard, depending on which operating system is being used.

The last commit that was created during this stream can be found here:

https://github.com/gep13/clipimg-vscode/commit/299e3cfe22d0440f731e2af150e4731f076bdb65

In this stream, I started building a new VSCode Extension. The function of this extension is to take the contents of the clipboard, and upload it to Azure Storage, and then output a markdown snippet to the current open markdown file. This will dramatically improve the workflow that I use for writing blog posts, documentation, etc.

The stream started with using the yeoman generator to scaffold out a new VSCode extension, and then make use of the Cake.VsCode.Recipe package for Cake to run a build of the extension, and generate the vsix file. This was then connected to AppVeyor, so that every commit to the GitHub repository results in a build being executed.

The commits that were completed in this stream can be found here:

• https://github.com/gep13/clipimg-vscode/commit/a8ce60f9c4b75d2505917460d911249f6e97a6f7
• https://github.com/gep13/clipimg-vscode/commit/7f1db4cd7188ab14a92f4f71cbdc9fd286eac518
• https://github.com/gep13/clipimg-vscode/commit/13e9ab0814d8116b9604425fa9a2d8c130907161
• https://github.com/gep13/clipimg-vscode/commit/4c80e8a06bab0e87983037f059ede232987d11cd

Setting up of the AppVeyor build results in some failures, which were as a result of a bug in the Cake.VsCode.Recipe package. An issue was created here:

cake-contrib/Cake.VsCode.Recipe#2

to cover this.

In this stream, I was joined by Martin Björkström, and we started looking at implementing a C# Language Server for validating a Chocolatey nuspec file which is opened within Visual Studio Code. This used two nuget packages:

• https://www.nuget.org/packages/OmniSharp.Extensions.LanguageProtocol/
  • for creating/instantiating the Language Server
• https://www.nuget.org/packages/GuiLabs.Language.Xml/
  • for parsing the XML of the nuspec file

The code that was discussed in this stream can be found in this repository, which Martin created. This shows the complete prototype of the C# Language Server running within Visual Studio Code, and validating the nuspec using the Schema and also a custom rule for templated attributes.

More information about the official Language Server Protocol can be found here.

And the blog post that Martin mentioned in the stream about creating a Language Server can be found here

In this stream, we delved into the Spectre.Cli library, and how it can be applied to an existing command line application, in the form of GitReleaseManager.

This was my first stream with a guest on the show. This was Patrik Svensson, the creator of the Spectre.Cli library.

This stream consisted of showing how to go about setting up Spectre.Cli, and showing how to begin creating the command structure that a CLI application will use.

The output from this live-stream can be seen in this commit here:

https://github.com/GitTools/GitReleaseManager/commit/4d1e3ae53bdcb2481fc588ae9348ab72a535757e

There is still some work that needs to be done here to finish off this work, including creation of additional commands as well as the settings for each command, however, the framework for all of this has been laid, so it should be reasonably simple to implement. As mentioned on the stream, a good example of everything that can be done with Spectre.Cli can be seen in this PR:

cake-build/cake#2334

Which is re-writing the Cake command line parsing to use Spectre.Cli.

In this stream, we continued talking about how to extend the Chocolatey CLI with a new command, choco export.

This included a brief discussion about how Unit Testing is done on the Chocolatey code base, and the need to install the NUnit 2 Test Adapter so that the Test Explorer reports success/failure correctly.

There was a little bit of a side line discussion about the correct encoding to apply to a file, which we eventually got figured out.

The output from this live-stream can be seen in this commit here:

https://github.com/gep13/choco/commit/b5fa2f079700dab1f6e347df57ba93b1b64cc44a

There is still some work that needs to be done here to finish off this work, but the additional arguments that have been added make it much more functional.

In this stream, we talked about how to get started with the Chocolatey Source Code, highlighting a couple of known stumbling blocks that people run into.

• Missing SolutionVersion.cs file
• Requirement to install dotnet 3.5
• Running with a second instance of Chocolatey

From there, we started implementing a new Export command, that can be used to export the current list of packages into a packages.config, which could then be passed into the choco install command on another machine, or when re-building current machine.

The output from this live-stream can be seen in this commit here:

https://github.com/gep13/choco/commit/9ca6f01b6f7619a438833e3c01107ad0e7bd6a3a

There is still some work that needs to be done here to finish off this work, but it is at least functional for this first pass.

In this live stream, we talked about the end to end process of setting up a complete CI/CD pipeline for a new Cake addin. The included setting up of:

• Appveyor
• Cake.Recipe
• xUnit Tests
• Code Coverage with OpenCover
• Publishing Code Coverage metrics to coveralls.io
• Mergify
• Dependabot
• GitVersion
• GitReleaseManager

At the end of the video, the new Cake addin was successfully submitted to NuGet.org as part of the release, and a tweet and Gitter message were automatically sent out to the community to let them know that the addin is available.

In this stream, we talked about how the Moderation Process for the Chocolatey Community Repository works. This included the automated services that occur, including package_verifier, package_validator, package_scanner and package_cacher. Following that, we discussed the manual review process that happens by one of the moderators of the Community Repository. Finally, we addressed the usage of the package_cleanup service for tidying up unmaintained packages, and finally, using the Chocolatey Test Environment when creating/maintaining packages.

In this stream, we talked about how to use Sonatypes Nexus Repository to cache packages from the Chocolatey Community Package Repository locally on your machine/environment, so that they don't need to be downloaded each time they are required. This can help if you are running into the newly implemented Rate Limiting feature on chocolatey.org.