[go: up one dir, main page]

Skip to content

BlogΒΆ

Updating pre-commit additional dependencies using Renovate

I am a huge fan of Renovate Bot to automatically update dependencies in projects. I use it in all my projects. At the time when I discovered it, we were using GitLab so we could not use dependabot.

In general, I quickly realized that Renovate Bot has significant advantages over dependabot (which, if I am not mistaken, is restricted to running on GitHub). Renovate is fully open source (and can be self-hosted), highly configurable, supports many dependency managers, supports custom managers with regex, and much more.

Renovate has been having beta pre-commit support for quite some time which needs to be enabled explicitly. I have been using it for a while and it works great in keeping up-to-date with updates to pre-commit hooks (it is generally recommended to pin dependencies).

pre-commit hooks can have additional dependencies. These additional dependencies are specific to the language the hook uses. For example, let's assume you are using mdformat to format your Markdown files which supports additional plugins. mdformat is a Python tool so the additional dependencies are Python packages.

Here is an example pre-commit config that this website uses as of this writing:

.pre-commit-config.yaml (excerpt)
  - repo: https://github.com/executablebooks/mdformat
    rev: 1.0.0
    hooks:
      - id: mdformat
        language: python
        args: [--number, --sort-front-matter, --strict-front-matter]
        additional_dependencies:
          - mdformat-mkdocs==5.1.4
          - mdformat-front-matters==2.0.0
          - mdformat-footnote==0.1.3
          - mdformat-gfm-alerts==2.0.0
          - mdformat-ruff==0.1.3
          - ruff==0.15.4
          - mdformat-config==0.2.1
  1. Specifying the language is optional but important here as you will see when you keep reading.

How can we ensure that the additional dependencies receive get updated automatically as well?

Using semantic-release with an SSH deploy key in GitHub Actions

We use semantic-release to release new versions of one of our JavaScript-based web applications. semantic-release can help with various release-based activities, such as figuring out the version bump based on the commit history using conventional commits, updating the changelog, pushing a new version tag, and so on.

We recently migrated our repositories to GitHub and have a ruleset enabled for the main (default) branch to protect this branch. Using a ruleset is basically the new way of protecting a branch. For a single developer or a very small team this might be overkill and slow you down. For bigger teams definitely it makes sense to ensure that certain practices are adhered to. For example, you can enforce that force pushes are getting blocked, or that a pull request is required before merging.

This is where we ran into issues where the release commit by semantic-release could not be pushed directly to main due to this rule. GitHub allows you to grant bypass permissions for your ruleset. Unfortunately, you cannot add a single user to this bypass list, and the GITHUB_TOKEN secret is associated with the (special) github-actions[bot] user.

So, how were we able to accomplish this?

Authenticating as a system user with OpenEMR's FHIR API using OAuth2

At Opal we want to support the current industry standard in healthcare integration which is SMART on FHIR. This also makes sense given that Opal has a partnership with OpenEMR which supports this standard.

In this article I describe how to authenticate a backend service using the client_credentials grant in Python in two different ways (i.e., with two different packages). For example, this is required when making use of the Bulk Export API.

Formatting Markdown files with mdformat

At some point I was looking at the .pre-commit-config.yaml that the ruff project uses. Looking at how other projects do things, what tools they use, how they work, etc. is a great way to learn. I noticed several pre-commit hooks that were interesting, one of which was mdformat.

mdformat is "an opionionated Markdown formatter". It has a specific formatting style that cannot be configured. There are a few configuration options though.

The nice thing is that it has a plugin system giving you the ability to add support for syntax other than what is defined by CommonMark. In addition, there is also support for code formatter plugins to format code in fenced code blocks.

For example, for a project that uses mkdocs with the fantastic mkdocs-material theme (like this website uses), the mdformat-mkdocs plugin offers the necessary support. You can find the see the setup that this website uses in the corresponding .pre-commit-config.yaml.

Compatibility with markdownlint

I have been using markdownlint for a while. Since both tools support CommonMark they are basically compatible.

I run both tools via pre-commit hooks. First, mdformat, and then markdownlint-cli2 so that the linting is done on an already formatted file.

The one thing that does not work, unfortunately, is when you use a comment to disable a certain markdownlint rule for the next line. mdformat adds an empty line in between the comment and the next line invalidating disabling the rule.

Stopping VSCode Python Extension from Changing your Terminal Environment

I have tripped over an outdated environment variable a few times when running Python from within vscode. And I finally figured out what caused it.

We store our environment variables in a .env file that is then used by our Django application. We use the django-environ package for this. During development, this file is loaded on startup. When deployed, we provide the file via env_file in the compose file.

What happened in vscode is that when a value in .env changed, running something, such as pytest, would not see this new environment variable value.

After a while I noticed that there was a yellow warning sign next to the terminal process. When hovering over it it asks you to relaunch the terminal because the environment changed. It took me a long time to figure this out in the first place. It's not something I expected and not very intuitive.

I had looked in the past in the settings where this is coming from and how this can be disabled and could not find anything. Today I finally figured it out, after running into this issue again and wasting time until I realized why something did not work.

The popup shown when hovering over the allows you to "Show Environment Contributions". The Python VSCode extension contributed the variables and causes this behaviour. In Settings > Extensions > Python there is an entry called "Env File" that contains ${workspaceFolder}/.env. Remove the value and relaunch the terminal.

Now changes to your .env file won't affect your terminal's environment anymore.

Blog Relaunched

My blog has existed since 2011. The intent has always been to share knowledge I gained, whether this be for someone else, or just for my future self. From the beginning I used Wordpress which makes it quite easy to set up a blog. There are also tons of themes and plugins that you can install and use.

Writing (especially in public) is not super natural for me. Doing it in WordPress did not feel natural to me either. So for a while I was dredding to create new blog posts because it was too cumbersome for me multiple reasons.

Another difficulty was keeping WordPress up to date along with the plugins and any customizations to it. While it is fairly easy to customize CSS, JS, or the PHP code of themes and plugins, there is no easy way to keep those separate so that themes and plugins can be easily updated.

I switched to a containerized setup, putting as much as possible in a repository. This included customizations. My idea was that it would be easier to update themes and plugins and re-apply those customizations. In the end, it was still too much manual work, however. It's not as easy as merging a dependency update on your repository raised by Renovate (of which I am a huge fan) and automatically re-deploying.

A few years ago, I came across the amazing Material for MkDocs. It is a technical documentation theme for MkDocs with many great features. Documentation is written in Markdown and can be version controlled in a repository. This is basically "documentation as code".

I first introduced it at work a few years ago for various documentation sites. Together with Material for MkDocs this has been fantastic.

Since Material for MkDocs has a blog plugin I've been wanting to switch to this for a while. I knew that this will allow me to write blog posts more naturally (in a text editor) and treat everything as code. I finally got around to it and migrated my old WordPress site to what is now a static site.

It is live now πŸ˜„.

Keep reading if you are interested in the details of how it is set up.

Linting Markdown files in GitLab CI

A while ago I was looking for a way to lint Markdown files and came across markdownlint in my search. There are two CLI tools for it, markdownlint-cli and markdownlint-cli2. Based on the comparison and rationale by one of the authors I gave markdownlint-cli2 a try first.

It is node-based and has lots of supported ways of invocation, such as a pre-commit hook, works well with the markdownlint vscode extension, and can be run as a container (including an image containing custom rules).

We are using GitLab which has code quality scanning support. You can import code quality results from a CI/CD job. Depending on the tier you have, you can see code quality findings in various places in the merge request UI helping the merge request author and reviewer(s). The code quality findings are provided as a JSON file during a CI/CD job. The report format is based on the CodeClimate report specification.

There was unfortunately no support for this yet. At first, I wrote a custom formatter that lived in our private repo. But instead of leaving it buried in a private repo, I wanted to make it available to all our own repositories and the markdownlint-cli2 community. I checked if there was appetite for integrating this into markdownlint-cli2 and ended up contributing a code quality formatter. It is published as an npm package: https://www.npmjs.com/package/markdownlint-cli2-formatter-codequality.

Open Sourced Toggle Headers Thunderbird extension

A long time ago I released the Toggle Headers extension for Thunderbird. I've kept it in a private git repository all this time (it might have started in a Subversion repository even).

This was way before I really got into open source. Recently, a member of the Thunderbirds Add-ons reviewer team sent in a fix and asked if I was willing to open source it to make contributions easier.

So I did open source it, and added a PR to fix compatibility with newer Thunderbird versions. I attributed this change to the reviewer who submitted the patch via email.

At the same time, it gave me a chance to create a script that allows me to build the add-on file. I had used ant before but given that it is only a ZIP file I wrote a small script in Python which makes it a lot easier to run.

Even though I don't use Thunderbird currently anymore, I find it important to keep maintaining the add-on. There are still a few users making use of it every day πŸ˜„