The final step in my efforts to automatically announce new blog posts to social media from GitHub Actions was the actual act of posting the prepared message to selected social media platforms. After a bit of search and testing, I managed to find existing actions for all my platforms of interest.
In my quest to automate announcing of new blog posts to social media using GitHub Actions I managed to find existing actions for most steps in the process. However, the act of composing the final message from the collected data was just too specific to my needs and there was no way around writing some custom code. I ended up creating a private JavaScript action for that.
I decided to automate posting announcements to social media platforms when I publish a new blog post. Since I'm already using GitHub Actions to publish blog posts on schedule as well as deploy any changes to the site, I wanted to use the same for social media posting as well. The first step was finding out if a blog post is being published with a particular deploy and gathering some information about it.
For the command line tool I was working on recently, I decided to distribute it as a .NET tool. It didn't have anything to do with .NET, except for it being developed in .NET, and the few potential users being .NET developers. That's also why I didn't want to publish it to NuGet Gallery at first and was considering the GitHub Packages NuGet registry instead.
As I wanted to make my side project more easily available to others by releasing it to GitHub and NuGet, I tried automating this step in GitHub Actions as well. It took me less time to get it working than expected.
Authenticating with the GitHub API using a personal access token is perfectly fine if you're performing a one-time task for yourself. However, you're better off authenticating as a GitHub App if you're developing an automation for an organization and want it to do its job for a longer time.
Caching of NuGet packages can significantly speed up .NET builds in GitHub Actions, especially if your projects has many dependencies. The generic cache GitHub action used to be the only way to do that and I described how to configure it a while back in my article for DotNetCurry Magazine. However, recent versions of setup-dotnet GitHub action now have this functionality built in which makes the configuration even simpler.
The template I'm using for creating a new GitHub Actions workflow for .NET projects doesn't create any test and coverage reports, so that's usually the first thing I add to it. I've documented my approach in the past across two articles I've written for the DotNetCurry Magazine. But since the relevant instructions are interleaved with other topics and some details have changed since those articles were published, I decided to write this blog post with up-to-date information and focus only on this part of the workflow.
After creating a working dev container configuration for an ASP.NET Core with Angular project, I wanted to also try it out with GitHub Codespaces. I had to do additional changes to the configuration to get it working.
After I set up a self-hosted GitHub Actions runner on my Synology NAS, it only worked without issues until a new version of the image had been released. Since I couldn't get automatic updates working with my setup, I settled with a manual update process for the time being. When a reader suggested that I could use Watchtower instead, I decided to try it out when the next version of the runner is released.
After I set up a GitHub self-hosted runner on my Synology NAS, it worked great for a while. Then, on a random Saturday morning, I got an error notification. It turned out that the runner was trying to update itself, but it failed to restart at the end.
GitHub Copilot for CLI is an NPM package which you can install and use on Windows if you have Node.js 16 or newer on your machine. However, the official setup only makes the commands available in zsh and bash. This means that you can only use it in WSL, but fortunately, there are also ways to make it work in PowerShell.
I've been using Disqus as a comments engine on my blog since I switched to a statically generated site in 2015. Since then, I grew increasingly dissatisfied with it, primarily because of its unreliable notification system and complex administration panel. This post documents the steps I took to replace Disqus on my blog with utterances.
Git doesn't restore file timestamps by default. So the file timestamp indicates when the file was cloned locally. And in most cases that's fine. But such a timestamp will prevent you from detecting if a file on a remote server has changed since it was last committed.
Although GitHub-hosted runners should usually be your first choice for running GitHub Actions, you sometimes still might want to use a self-hosted runner to save on costs or work around IP blocking. If you own a Synology NAS, you can also use it to host a GitHub runner.
FTP is still one of the most common methods to upload files to your web server. So it's not surprising that there are (too) many GitHub actions for it. However, if you want to download some files (e.g. to backup/commit content that was edited online), you are mostly out of luck.
GitHub Actions can be a good choice for deploying an ASP.NET Core application to an Azure Web App Service if you have the code in a GitHub repository. You can even generate the GitHub Actions workflow directly from the Azure Portal. However, if your solution is not very simple, the generated workflow may not work correctly.
When I was looking into GitHub Actions, I found an example configuration for dependency caching that seemed wrong to me. It specified that a unique key for caching dependencies should be generated by hashing all files named package.lock.json in the repository. I would expect the *.csproj files to be used instead.
GitHub Actions provide a default GITHUB_TOKEN that can be used by steps in your workflow that require access to your GitHub repository. However, some actions require more permissions than others.
For quite some time I have been regularly publishing new blog posts every Friday morning. I have the code for my blog in a GitHub repository. Each unpublished blog post that I have prepared in advance is in its own branch. To publish it, I just need to merge it with the main branch, which triggers the GitHub workflow I set up to deploy the blog. But while this does not take much time, I finally decided to look for ways to automate this last step.
Most of my blog posts have an accompanying GitHub repository with sample source code. On average, I create one such new repository per week, and they all share most of their configuration options. I looked at several options for automating repository creation to speed it up and reduce the likelihood of misconfigurations due to human error. The option I liked best was GitHub CLI and its alias command.
Since the introduction of GitHub Actions there's often no need any more to use an external CI/CD service. After I moved my blog repository from BitBucket to GitHub it was time to move my continuous deployment configuration from CircleCI to GitHub Actions as well.