Cool makefile target for Golang mocks generation

One thing I found a bit annoying when I first started coding in Go is that if you want to unit-test your code built around interfaces, you always need to write the mocks that implement interfaces.

Unlike Java, there is no proxy magic like mockito that allows you to state ‘I want a mock that implements this interface’ right from your unit test, and the magic creates the object for you.

Nope. In Go, thou shalt code a mock that satisfies this interface and implements every single one of its functions.

Luckily, there are libraries to generate mocks: personally, I use vektra’s mockery.

It is pretty simple to use, decently documented, and it does the job pretty well. Just be aware that on Windows machines, you might need to manually fix imports of vendored libraries.

Anyways, it is no magic wand: from your unit test, you still need to instruct the mock on how to behave when called.

If you like the idea behind it and want to give it a try, I’d suggest you to first play with it just to generate the mock for one or two interface.

And if you like what you saw and want the generation automated at project level, you can check out this Makefile target I use at (don’t be scared by the big command – explanation will follow 😃):

.PHONY: update-mocks
    go get -u

    go list -f '{{.Dir}}' ./... \
    | grep -v "$(notdir $(CURDIR))$$" \
    | xargs -n1 ${GOPATH}/bin/mockery \
       -inpkg -case "underscore" -all \
       -note "NOTE: run 'make update-mocks' from bookkeeping-worker top folder to update this file and generate new ones." \

So, let’s take a deep breath and dive in the commands:

  • Lines 1 and 2 declare the target ‘update-mocks’ – to run it, you’ll then do ‘make update-mocks’.
  • Line 3 downloads (or updates) the mockery tool
  • Lines 5 and 6 list all folders that contain go files – I don’t run recursively on ‘.’ because that would cause mockery to get into vendor folders
  • Line 7 calls mockery for each folder
  • Line 8 adds three options, for, respectively:
    • generating mocks in the same package as the mocked interfaces instead of creating a ‘mocks’ dedicated package (it is generally safer to use this option even though it’s not default)
    • naming mock files in snake_case
    • generating mocks for all interfaces found
  • Line 9 adds a note in generated files to explain developers how this file was generated, and how to update it

If you like it, use and customise it to your needs…. if yours is a small project, you can simplify this command a lot: for example, for projects with no vendor folders, the second command can become:

    ${GOPATH}/bin/mockery \
      -inpkg -case "underscore" -all \
      -note "NOTE: run 'make update-mocks' from bookkeeping-worker top folder to update this file and generate new ones." \
      -dir .

How do I kill a stuck Jenkins build?

Sometimes, Jenkins builds simply get stuck, and aborting them from the job page does not help.

If this is your case, then, you can do something with it:

  • read your build job’s full name and, the build number that you wan to terminate

Jenkins.instance.getItemByFullName("<job_full_name>").getBuildByNumber(<build_number>).finish(hudson.model.Result.ABORTED, new"Stopping this build without being polite."));

How do I know what images are stored in a private Docker registry v2?

You have two options:

  1. Set up a web-based browser – this will require you more work to set up and maintain, but will give you much easier way to browse the repo
  2. Browse manually the repository – requires no setup, you will find what you look for in a minute, but it’s not greatly user friendly

If you go for solution 1, there are a few implementations, that can be even downloaded as docker containers (like docker-registry-web ).

If you go for solution 2 (which is what this post is about), you only need to perform two steps with your browser:

  1. list what are the repositories

    This will give you a JSON list of repositories… just find one of your interest

  2. list the tags for a it

(source: Stack overflow – snth’s answer)


Jenkins can boot and shutdown slaves when needed

While configuring distributed builds with Jenkins with slaves on Amazon EC2, your first setup could make use of on-demand instances.

Meaning that Amazon manages some machines that you could start (boot) and stop (shutdown) whenever you want. Amazon bills you for the time these machines are running.

So if you want to save some money, you want these machines to be running only when you use them: in the case of Jenkins slaves, only when Jenkins has something to do on them.

Amazon helps you, by providing you a console interface that can be scripted, and plugged to other logic in Jenkins, but what could be this logic?

The Slave setup plugin lets you configure slaves as “on-demand”, by providing a hook (1) that allows you to specify – right in the configuration of the slave node – a script to be executed before connecting (2) and another one to be executed after disconnecting (3).


You can find more details in its documentation (section “on-demand slave setup”).



When deleting files in a docker container, the DM pool doesn’t free up space

System: long-running container that creates/delete files. Host is a RHEL7.2 (kernel 3.10.0-327.el7.x86_64) machine, with Docer v1.8.2 backed by a “loop-lvm” devicemapper pool.

Symptom: despite the container also deletes files, the available space in the devicemapper pool only shrinks and never increases.

Possible solution: run “fstrim /” from inside the container. Note that this requires you to run it in ‘privileged’ mode.


Tweaking docker devicemapper storage in Red-Hat based distributions

If you are using docker on Red-Hat based distributions, then devicemapper is your default filesystem for backing docker.

In case you want to change some of its default settings (i.e. if pool size of 100Gb is not enough), have a look at the “real docs” for RH7 or at this page for other distributions.

If you want to dig deeper, in this other page you will find a pretty detailed comparison of the different filesystems options available for RH.


Executing a shell in a running docker container

In case you have a docker container on which you need a shell, and you don’t have it (e.g. it runs in the background, no sshd runs on it, …), you can have a shell on it by executing:

docker exec -it <container_name> /bin/bash