Tips-and-Tricks on stuartleeks.com

Fun with WSL, GitHub CLI and Windows Notifications

Thu, 27 May 2021 13:42:16 +0100

Introduction

In the last post we saw how to create a drop-in replacement for notify-send. This allowed us to take a script that used notify-send and run it without modification. In this post, we’ll take a look at how we can update that script to take better advantage of Windows notifications.

At the end of that post, the notification was fairly generic as shown below:

Fun with WSL, GitHub CLI and Windows Notifications

Thu, 27 May 2021 07:10:16 +0100

Introduction

I’ve been making use of the GitHub CLI and finding it a productive way to work with GitHub. Recently, Lawrence Gripper shared with me a handy alias that he had set up:

alias ghrun="gh run list | grep \$(git branch --show-current) | cut -d$'\t' -f 8 | xargs gh run watch && notify-send 'Run finished'"

This ghrun alias finds the latest GitHub actions workflow for the current branch and starts a gh run watch for it. This shows the progress through the steps of a workflow:

Forwarding copy to clipboard from dev container to Windows Host

Wed, 17 Feb 2021 19:11:12 +0000

Background

I’ve mentioned VS Code dev containers on this blog before and like using them from WSL.

I’m also a fan of azbrowse for working with Azure resources from the terminal, and lately have found myself running azbrowse from within a dev container for various reasons.

There are several features in azbrowse that copy data to the clipboard, and when run from WSL it detects that and copies to the Windows clipboard, which is convenient. When run from a dev container, the experience isn’t so good (a polite way of saying that it doesn’t work).

Forwarding SSH Agent requests from WSL to Windows

Fri, 03 Jul 2020 15:11:12 +0000

Background

As I mentioned in my previous post, I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and found it a positive experience. At first I was a bit lazy and didn’t use passphrases on my keys, and just kept a copy of my keys in the .ssh folder in my User folder in Windows and another copy in ~/.ssh in WSL.

For day-to-day working this worked okay, but I finally got round to adding passphrases to my keys a while back and was less happy with the setup at that point. My previously suppressed niggles around having the keys in multiple places re-surfaced once I had to add handle passphrases in multiple systems on the same machine!

Fun with Git for Windows, SSH Keys and Passphrases

Tue, 30 Jun 2020 14:18:36 +0000

Disclaimer: this post is one to file under “things I’m blogging in the hope that I find the answer more quickly next time”.

Background

I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and never looked back. For a while I was using SSH keys without passphrases but got round to adding passphrases a while back. I set up the Windows OpenSSH Authentication Agent - the service defaults to Disabled so I set it as Automatic start and nudged it to Running. (For more information, see the docs on installing Windows OpenSSH)

Working With Multiple Kubernetes Contexts

Fri, 24 Jan 2020 20:24:13 +0000

If you’re working with Kubernetes then there’s a pretty good chance that you’ve been working with kubectl!

There’s also a pretty good chance that you end up working with more than one cluster context. So, how do you manage multiple contexts?

KUBECONFIG

One way that you might have encountered is obtaining a kubeconfig file that contains the details of how to connect to a cluster. kubectl allows you to pass a --kubeconfig option to commands to specify which kubeconfig should be used to connect to a cluster to execute the command. E.g. kubectl get pods --kubeconfig=/path/to/kubeconfig.

Working With Git Rebase in Visual Studio Code

Thu, 23 Jan 2020 08:15:27 +0000

Following the git theme for mini-posts, I thought I’d give git rebase a mention this time.

When I first started working with git I found a way to pretend that it was a source control system like any other that I’d used. Eventually, I was working on a pull request for an OSS project and a maintainer asked me to rebase my changes. Now, I’d heard of rebase at that point but I hadn’t used it, so I was a bit daunted. So this post has a few tips that I wish I’d known at that point. By way of encouragement, I’ll add that getting familiar with git rebase is a huge part of the reason that I love git and has improved my developer workflow.

Setting Visual Studio Code As Your Git Editor

Wed, 22 Jan 2020 07:17:34 +0000

My last post seemed to go down quite well, so I’m going to try a few mini-posts with a ’tips-and-tricks’ theme. This works well for me as I’d started making some notes about productivity tips I use as part of my prep for an internal no-prep presentation ;-)

This one is a really small tip that is covered in the Visual Studio Code docs, but lots of people using Visual Studio Code seem to have missed it so I’m going to mention it here: you can set Visual Studio Code to be your git editor. To do this run:

Working With Pull Requests in Azure DevOps

Fri, 17 Jan 2020 13:16:36 +0000

I like working at the terminal. No judgement if you don’t, but for me the terminal feels like a comfortable and productive place :-)

I also like to find ways to gradually improve my experience with the terminal, and a while back I mentioned to Lawrence that I’d created some git aliases to help me easily check out pull requests on github. He immediately replied pointing me to github.com/ldez/prm (Pull Request Manager) which is an awesome tool for checking out pull requests locally and working with them.