Github Actions released, and some specifics for .Net Framework

Summary

Github Actions has been released for public use, and announced at the Github Universe conference in San Francisco Nov. 13th. And, because Github loves open source - it is fully free for all public repositories!

Github Actions can be used for automating a series of processes, as it can utilize most of the events in the github system. The most typical use will still be to trigger CI/CD builds. The whole system is yaml based, and it can run on different environments, Linux, Windows and MacOS.

This post came about as a result of a an interesting question raised by my good friend Richard Hundhausen in Accentient. It turned out into some very interesting observations, and a few ways of handling this.

Background

When you’re starting up a new git repository for a Visual Studio project, you need a .gitignore file that matches. The gitignore file ensures that working files and folders that are not to go into source control are kept out. As Visual Studio and its extensions are growing, this list of files and folders are increasing. You need to have a gitignore file that at least matches the version of Visual Studio you’re using. Most developers notice files that they don’t think should be in source control, and exclude those (and then adds them to the gitignore file they have), but in many cases they don’t even know what that file is for, and it is inadvertently added in. Normally not causing any problem locally for that single developer, but then it may fail for the next developer down the line, or it may fail during CI builds. So it is much better to get the correct and full gitignore file when you start up your project. Less work later! And what could possibly go wrong?

The former post in this series showed how you could add aliases to the git command line, and showed how some simple aliases can simplify your command line work.

This post show how you can extend that to work more actively with the Azure DevOps (formerly known as VSTS)  server hosting your repository. (If you don’t have an account here, please consider doing that, it is free for modest individual use!)

You can do all of this from the combination of Visual Studio, and the web browser, but going through all those UI’s is like a good friend said: “and after 56 more clicks…..".   Using the command line is just so much faster - but in order to be effective the number of parameters must be cut down to something manageable.  And that is what this is about!

The most basic Git commands are built into the Visual Studio Team Explorer.   The Team Explorer will cover your basic needs, but once you get beyond that, you will need to drop down to the command line.    The commands are more explicit there, and you have more options, but you will soon tire of having to repeat the same basic commands again and again.  Enter the Git aliases – and you can easily make your most used commands so much more short and effective. 

I have had a need to have more easy access to information on how to do certain stuff, and have some easy access to simple code blocks, or templates, I can copy/paste.  A blog post is for me somewhat more extensive, and that format was not really suited for smaller notes.  So I decided to write them down as “recipes”, which is a small post, larger than a post-it, but smaller than a full blown blog post.

Visual Studio 2017 lack a proper internal terminal.  The Command Line extension has been a good substitute, but it opens up in a separate window.  If you work with multiple Visual Studio at the same time, you loose track of which command window belongs to which Visual Studio instance.

Visual Studio Code has it's own Terminal window built-in, so why not Visual Studio itself?  Well, now it is here, a pre-pre tool called Whack Whack (named so because of how you open it).  

It runs default with Powershell, and if you have installed Posh-git with your powershell, it also lights up inside WhackWhack, which is super cool!  If you don’t know posh-git, it adds some cool extras to the command prompt for git, like shown above – you see the current branch and the git status straight off the command prompt and tab completes for commands and branches.

You can download the Whack Whack terminal from the Visual Studio marketplace, and the project is open sourced at Github.

Download:  IFix 1.7

When I start creating a new solution I normally want this in its own git repository, and I catch myself adding the same stuff over and over again.   And, I often get the folder structures wrong,  I seem to never get the hang of when and where Visual Studio creates a folder for the solution, why the solution ends up at the same place as the first csproj file, and I often end up moving things around to get it the way I want it.

This post is written for those going from TFS Version Control to Git, and is an introduction to a smart improvement in Visual Studio 2015 - Commit Amend. Command Line enthusiasts already know how this is done, but it may still be useful to see how this is resolved in Visual Studio.

In TFS VC  the checkin command is used to add files to version control. The command saves the file to the central TFS VC system. When using Git you operate on your own local git repository first - by committing changes to the local and then you push these changes to the external remote repository.

The .gitignore file contains rules for what files and folders to exclude from git source control.  When you use NuGet you don’t want the binaries retrieved by NuGet to be included into your git repository.  The binaries (and other files) from a NuGet package is downloaded into a folder named packages by default.   You need to add some rules to the gitignore file to exclude this folder from the repository.

Download tool

Updated 3.July 2014:  Corrected pattern for NuGet, details in this blogpost. (IFix is in progress to be updated too, version 1.1 will have these fixes)

Is there anything wrong with the built-in Visual Studio gitignore ????

Yes, there is ! 

First, some background:

When you set up a git repo, it should be small and not contain anything not really needed.  One thing you should not have in your git repo is binary files.