Releasing DataLeaf

DataLeaf uses a controlled GitLab CI job to create version tags and GitLab releases from reviewed main commits.

Before publishing:

1. update CHANGELOG.md;
2. add or update RELEASE_NOTES_<version>.md;
3. verify the merge request pipeline;
4. merge the release preparation to main;
5. verify the main pipeline and GitLab Pages deployment.

Open Build > Pipelines > New pipeline in GitLab and select the main branch.

Add:

RELEASE_TAG=v0.1.0
RELEASE_NOTES_FILE=RELEASE_NOTES_v0.1.0.md

Run the pipeline. After validation, quality checks, and the Pages deployment pass, select Run on the manual publish-release job; until then the pipeline shows as blocked.

The job creates the missing tag at that pipeline’s exact main commit and publishes the GitLab release using the committed Markdown file as its description.

Building, validating, and deploying the documentation happens automatically. Publishing a version is deliberately opt-in because it creates a permanent versioned reference consumed by downstream sites.

The release job cannot run from merge requests, ordinary pushes, schedules, or tag pipelines.

The job uses Node’s built-in HTTP client with GitLab’s Releases API and CI job token. No personal release token or CLI installation is required. Only tags that Go modules list are accepted: vMAJOR.MINOR.PATCH with an optional prerelease and no build metadata. The exact matching notes filename is validated. Existing tags must resolve to the pipeline commit; duplicate releases and API errors fail before publication.