For everything in life there is a JetBrains product. Right? Right.
So for C# development when using Linux, I wanted to use JetBrains Rider.
All went well, I needed to upgrade to Ubuntu 21.04 to install dotnet, but surprisingly, that all went off without a hitch. No full OS reinstall needed! Miracles do happen. I should put on a lottery ticket.
Anyway, by and large my dotnet’ing then went well enough. At least for the stuff I was doing (tutorials and exercism exercises, mainly). But then one day (today, just now) I wanted to debug something, and when I tried I got the message:
Mono location is not specified in settings correctly and can not be discovered automatically. Please check Mono settings under File | Settings | Build, Execution, Deployment | Toolset and Build
Being a dotnet newb, I didn’t fully understand why / what Mono is. As best I recalled from some previous work with Unity, Mono was a kind of editor that worked cross platform? Is that even the same thing? Who the heck knows.
Anyway, after a few failed attempts at fixing this following anonymous folk on StackOverflow (copy > paste > run > curse!), I discovered the answer. Very simple. Bit of a face palm moment:
Another day, another cryptic error message from Docker.
Right, so here’s what I was trying to do.
Blindly following the Playwright docs for getting a Playwright Docker container up and running, I first created a new file, seccomp_profile.json inside the current directory. The location of this directory is irrelevant, just the file needs to live in the directory from which you (or I) run the command.
And the command is directly lifted from the 1.14 docs:
When doing this, I got the error above, but for clarity (and for SEO purposes) here it is again:
docker: Error response from daemon: Decoding seccomp profile failed: json: cannot unmarshal array into Go value of type seccomp.Seccomp.
This tells us that whilst the file was read, the contents are somehow wrong.
I’m just going to skip straight to the fix here, as I tried a few things and got lucky. Sadly, I don’t know jack about Golang, but I loosely understand the error above as saying hey, Chris, that JSON file doesn’t decode into a format my program is expecting.
Bit of an obscure one this, and given that I received absolutely no Google results, I’m guessing may be of little help to … well, anyone. But perhaps this is the price one pays for being an early adopter.
I created a GitHub actions workflow that ran a Makefile command. It looked something like this:
name: E2E Tests
on: [push, pull_request]
- uses: actions/checkout@v2
- name: make install
run: make install
- name: make serve
run: make serve
Excuse the crappy steps, I was / am still kinda experimenting with this workflow.
Anyway, what we really care about (and where the problem actually lies) is in what the make install command represents:
Don’t be put off if you don’t use / understand Makefile‘s, but if you don’t, they are pretty useful. Other solutions exist, yadda yadda.
Keen eyed readers will have spotted something potentially curious:
docker compose ...
Yeah, so I got this from a little info at the end of my local command line output:
➜ my-project git:(e2e-tests-setup) docker-compose
Define and run multi-container applications with Docker.
docker-compose [-f <arg>...] [--profile <name>...] [options] [--] [COMMAND] [ARGS...]
Docker Compose is now in the Docker CLI, try `docker compose`
(Excuse the formatting, WP does its own thing)
See that line at the very end. Why not try the new stuff, right? Who doesn’t love the shiny.
But herein lies the problem. Note, even the official docs aren’t (yet) consistent in what format they use.
The solution to this problem is super simple.
Use docker-compose for your GitHub actions commands.
The problem arises because GitHub actions thinks I’m trying to run docker commands, and must be using an older version of the Docker CLI.
Docker version 20.10.7, build f0df350
Run docker -v
Docker version 20.10.7+azure, build f0df35096d5f5e6b559b42c7fde6c65a2909f7c5
Anyway, my fix was to change the Makefile command to use docker-compose instead of docker compose:
And what bugged the heck out of me was that the project needed a manual restart each and every time I made a change.
Now, I found several tutorials that explain how to fix this, but none of them actually solved my problem. So here’s what I had to do – and sadly it’s not absolutely perfect, but it is 95% of the way there.
As ever, if you know a better way, please do share by leaving a comment. Thanks!
The Stuff Everyone Else Says
Google for this problem and there’s a set of steps you will find in almost every result:
Add the Spring Boot Dev Tools to your project dependencies. I am using Grade, so here’s what I had to do:
... other stuff