GitHub actions still have a couple of limitations when it comes to Docker:
- Docker is not available on macOS virtual hosts
- Docker is set to Windows-containers on Windows virtual hosts
Thus, a complete recreation of the previous build which built and tested on all three OSes is infeasible using Docker. But it works in Ubuntu and Windows and this post is how you do it.
Consider the following Dockerfile, perhaps the simplest in existence, which echoes back the argument given to it:
FROM mcr.microsoft.com/dotnet/core/runtime:3.0-alpine ENTRYPOINT ["echo"]
And this small script,
test.sh, which builds the container, runs it with the argument 42 and verifies that the output is the same as the input.
#!/usr/bin/env bash docker build -t hjerpbakk/example . ARGUMENT="42" RESULT=$(docker run --rm -it hjerpbakk/example "$ARGUMENT") if [ "$RESULT" = "$ARGUMENT" ]; then echo "container ran successfully"; exit; fi echo "container failed. Expected:" echo "$ARGUMENT" echo "but got:" echo "$RESULT" exit 1;
Surprisingly, 42 is not equal to 42. What is going on here?
GitHub has finally learned from GitLab and added GitHub Actions to their repertoire. It’s in beta now, but this means that we can use only GitHub for everything from code hosting, project management, CI and finally CD. All in one place. An alluring thought, but how mature is it?
I recently started a new project using ASP.Net Core 3.0 and decided to take GitHub Actions out for a spin.
I needed to benchmark a couple of CLI solutions today and found the wonderful tool hyperfine. It times arbitrary shell commands over multiple runs, giving you the mean execution time and other statistical variables. As command timings can vary significantly between runs, this is a live saver if you want to compare different commands with regards to run-time.
- Statistical analysis across multiple runs.
- Support for arbitrary shell commands.
- Constant feedback about the benchmark progress and current estimates.
- Warmup runs can be executed before the actual benchmark.
- Cache-clearing commands can be set up before each timing run.
- Statistical outlier detection to detect interference from other programs and caching effects.
- Export results to various formats: CSV, JSON, Markdown, AsciiDoc.
- Parameterized benchmarks (e.g. vary the number of threads).
I previously wrote about how you can create a list of all your tags, sorted by the number of posts using Jekyll. Güngör Budak had a much better idea; create a tag cloud sorted by post count. Since this solution doesn’t require plugins, it too is compatible with GitHub Pages.
My tags now look like this, and for the first time, I’m happy with my archives page.
Over the years, I’ve amassed quite a few posts on this blog, but I’ve never been pleased with my Archives page. I’m still not completely satisfied, but it’s now improved by showing the tags and the number of posts in them, in addition to a chronological ordering.
I achieved this using only a Liquid template. It doesn’t use any plugins and is compatible with GitHub Pages.
Some of my regular readers might get déjà vu; this is the return of ERROR bad Request-Line.
Taking screenshots of your app on every device and localization quickly becomes time-consuming. With 2 languages, 6 different iPhones and 10 screenshots, you are faced with 120 screenshots per release. If we increase the number of languages to 10 and add iPad support, this number explodes to 10 (languages) x 11 (devices) x 10 (screenshots) = 1 100 screenshots!
Xnapshot enables you to use C#, together with Xamarin.UITest, to automatically take the screenshots for you. Just derive from the abstract Screenshots class, implement one simple method per screenshot and use your time productively while your computer takes the screenshots.
This website is built using the excellent static site generator Jekyll. I write my posts in Markdown with a YAML front matter block that tells Jekyll these files should be processed according to the values specified. It works great but has one drawback.
What if you specify invalid values? Jekyll doesn’t care so long as the values are of the type expected by the variable. The result might not be would you’d like, but Jekyll will bravely try to build most of what you throw at it and you’ll need to visually inspect the site or the source to find errors. As a software engineer, this is no good. I need to fail fast, and if compilation does succeed, the resulting artifacts need to be verified by tests.
Enter my Jekyll YAML front matter validator.
Given the following front matter:
--- categories: - blog layout: post title: Jekyll YAML front matter validator meta_description: image: /img/ date: 2019-07-08T12:00:00.0000000+00:00 tags: - jekyll - dotnet - dotnet-script - docker ---
My validator will report the following errors:
imagecontains an incomplete path that will not exist on the published site.
- For this example, the
datewas also set in the future and Jekyll would not have generated the post to be published.
Software sucks, every day another bug. Today the bug was in the Visual Studio for Mac package manager.