In many organisations there are conventions on how Git branches should be named. As with all aspects of code quality, it is better to be able to identify these issues before they are pushed into version control.
There is not a hook that we can specifically use at the point that a branch is created, so the best we can do is ensure that commits are not made to the newly created branch.
This is just a quick post to announce that a new version of the generate_service.sh script is now available.
Instead of putting the source for this into this post, I’ve now committed it to a Github repository here: generate_service.sh. This version adds support for generating additional service files for accessories defined under a platform in Homebridge.
I have been testing this out with a Samsung Tizen based TV, but this has exposed another issue with Wake-on-Lan packets not being able to be routed from a Docker network without using host mode. I’m still investigating options to solve this, which will be another post (or defeat, time will tell).
Git hooks are a fantastic first step for identifying issues before code is pushed to a repository. However, the configuration files which control these client-side hooks cannot be committed to the repository and need to be configured on each client once the repository has been checked out.
In the NPM world, Husky is a tool which is used to maintain commit hooks through the package.json file, and integrates with the NPM build lifecycle to keep the contents of the local “.git/hooks” folder up to date. With this, I have been using commitlint for ensuring commit messages conform to a standard format, as well as ensuring code has had linting checks ran against it.
I had a look for a similar solution for Maven, but could not immediately find one. I wanted to find a solution that could be integrated with the Maven lifecycle, like Husky does for NPM.
Throughout this series of blog posts I am looking at how to manage third party dependencies in the software development lifecycle. Before we get into how to automate the process of checking library licenses and checking if they are up to date, it is worth looking at how to do this yourself.
In this blog post I will look at the tools available for scanning an Angular application, which would also work for any type of project using NPM.
As part of looking in to controlling the third party libraries which could be included for use by a project, I wondered if it was possible to effectively apply an approved whitelist at the Sonatype Nexus level. This would only be effective if developers and CI tools are restricted in their web access and cannot contact the central artefact repositories directly, and so are forced to use Nexus as a mirror.
It turns out that this is possible, and the Nexus documentation is pretty good if you know the pieces of the puzzle that need to be joined together to make this work. Roles, which can be assigned to specific users or an anonymous user, are made up of privileges. Privileges can include Content Selectors to restrict the results which are returned. When combining these things, we can effectively build a whitelist. As this approach is role based, different rules can be used depending on who the caller is.