Skip to content

2025

  • 3 min read

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.

  • 2 min read

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.