Programming

Kind of a note to self, a reminder of some NASA programming practices for the JPL code. I’m not a programmer myself but some, if not all, of those rules can be applied to my humble projects. Avoid complex flow constructs, such as goto and recursion. All loops must have fixed bounds. This prevents runaway code. Avoid heap memory allocation. Restrict functions to a single printed page. Use a minimum of two runtime assertions per function....

I am sure I am not the first to do it, but I have asked ChatGPT to implement a UUID v7 function based on RFC 9562. It did not get it right the first time, but after some back and forth, it gave me this answer: import time, random, uuid def generate_uuid_v7_fast(): ts = int(time.time() * 1000) & ((1 << 48) - 1) upper = (ts << 16) | ((7 << 12) | random....

I have managed a Gitlab instance for a couple of years, but for some organizations, Gitlab is overkill. For some people, Gitea is enough. However, Gitea does not have production-ready CI/CD yet. Fortunately, it’s possible to link Jenkins to Gitea. Here’s how to do it. In this post, we will first configure Jenkins to use agents in Docker. It is not recommended to run pipelines on the Jenkins host. You can run a static container or let Jenkins spin up containers on the fly....

Gitea is great when you want a fast, light and yet user-friendly git repositories. Alternatives would be Gogs, Gitlab or even Github. Gitea documentation tells you to use docker exec to perform a backup. However, this prevents you from using an additional volume to dump the backup into. Instead, I prefer to use a similar command using docker run. Assuming the following: the container network is called gitea_default, you only need this if you use an external database such as MySQL the container is called gitea the backup directory is in the current directory and named backups docker run --rm -it --network gitea_default --volumes-from gitea --volume $(pwd)/backups:/backups --user git --workdir /backups --entrypoint '/app/gitea/gitea' gitea/gitea:1....

It happens I recently had to install Gitlab and was a bit lost about what to do right after the setup finished, perhaps this will help. By default, Gitlab stores its data files in /var/opt/gitlab and its backups in /var/opt/gitlab/backups. It would be a good idea to use dedicated partitions for each of those directories. Let’s say you use /dev/sdb1 for Gitlab data and /dev/sdc1 for the backups. gitlab-ctl stop mkdir /mnt/gitlab mount /dev/sdb1 /mnt/gitlab mkdir /mnt/gitlab/backups mount /dev/sdc1 /mnt/gitlab/backups tar -C /var/opt -cf - gitlab | tar -C /mnt -xpsf - umount /mnt/gitlab/backups umount /mnt/gitlab mv /var/opt/gitlab /var/opt/gitlab....