development.md

Developer documentation

Local testing and development

In order to assist with developing mariadb-alpine, the following software is strongly recommended:

• a containerd runtime such as docker for desktop or lima
• a docker-cli compatible client (TODO more testing with nerdctl and podman)
• bash 4.0 or newer
• bash_unit - a bash testing framework
• shellcheck to validate shell script
• hadolint to validate Dockerfile
• shfmt to verify shell script style
• actionlint to validate github workflows
• prettier (and Node.js) for checking code/documentation style
• jq, curl and coreutils for generating the benchmark Check the CI lint workflow to see which versions are tested against, but stick to $latest as a general rule.

From here you can build an image (sh/build-image.sh) or run tests with bash_unit.

Cutting a release

To cut a release, you need to be a maintainer of the github repository. The repository contains secrets with enough privileges to push containers to Docker Hub.

Instead of tagging and building images locally, the release workflow is fully automated through github actions.

There are sanity checks in place to help you from making mistakes:

1. The workflow will only be run if there is no existing github or docker tag corresponding to the mariadbd version in `Dockerfile.
2. The workflow will fail if there are issues building or testing the container.
3. Only by changing

Create a release in your browser

1. Visit the overview for the Release workflow
2. Click the button "Run workflow". You should be greeted by three inputs:
   • Branch: stick with the main branch unless you know what you're doing.
   • Replace existing tag: This will override any existing git tags as well as releases on docker hub. Useful if you broke a release. Can also be used with choosing branch/tag to build in order to rebuild older versions
   • update :latest tag on Docker Hub: only do this when cutting new (read: latest available) stable release
3. Hit "Run workflow" and wait a few minutes. Should tests or building containers fail, no tags or containers will be published to Github or Docker.
4. Should you run into issues, file a new issue in the repository and assign @jbergstroem.

Create a release with gh cli

Very similar to a browser workflow, but pass options with -f.

1. Review available options: gh workflow view Release --yaml
2. Start a workflow with said options (-f for attribute, --ref for branch) or with default settings: gh workflow run Release
3. Follow status with gh run watch

Note: gh run will tail any active job, which most likely only is the Release job. You can view current workflows/jobs with gh run list or gh workflow view Release.