release: on-prem 2026-01-26-001

.cursor/commands/create-pull-request.md

@@ -0,0 +1,9 @@
+Create a new pull request in remote repository https://github.com/currents-dev/docker
+
+- use GitHub MCP
+- use only committed changes for analysis
+- update PR details based on the template from .github/pull_request_template.md
+- analyze the changes and provide a concise description:
+  - list high-level changes first
+  - provide hints on how to effectively review the PR
+- don't check any boxes in the PR description, human would have to check them

.cursor/commands/fix-ci.md

@@ -0,0 +1,7 @@
+Explore the CI checks in remote repository https://github.com/currents-dev/docker
+
+- use GitHub MCP
+- find the associated PR
+- use `.github/workflows/` to understand the CI setup
+- analyze the failures and fix them
+- ask questions if unsure

.cursor/commands/prep-release.md

@@ -0,0 +1,76 @@
+# Prepare Release
+
+Prepare a new on-prem release by updating version files, changelog, and creating a PR.
+
+## Instructions
+
+### 1. Get the version number
+
+Ask the user for the version number if not provided. Format: `YYYY-MM-DD-NNN` (e.g., `2026-01-23-001`).
+
+### 2. Check current state
+
+Before starting, check where we are in the release process:
+
+- Is a release branch already checked out? (`git branch --show-current`)
+- Are version files already updated? (check `on-prem/VERSION`)
+- Are changes already committed? (`git status`)
+- Is the branch already pushed? (`git log origin/main..HEAD`)
+- Does a PR already exist? (check GitHub MCP)
+
+Skip any steps that are already complete.
+
+### 3. Create a release branch (if needed)
+
+If not already on a release branch:
+
+```bash
+git checkout -b release-on-prem/<version>
+```
+
+### 4. Update version files (if needed)
+
+Update the following files with the new version/image tag:
+
+- `on-prem/VERSION` — Set to the version number
+- `on-prem/.env.example` — Update `DC_CURRENTS_IMAGE_TAG` to the version number
+
+### 5. Update the changelog (if needed)
+
+Follow the `update-changelog` command instructions, but with these modifications:
+
+- Instead of adding to `[Unreleased]`, **move** the existing `[Unreleased]` content to a new version section
+- Create a new section header: `## [<version>] - <today's date in YYYY-MM-DD format>`
+- Place it immediately after the `[Unreleased]` section
+- Leave `[Unreleased]` empty (or with placeholder subsection headers)
+
+### 6. User commits and pushes
+
+**Important:** Do NOT use shell commands for git commit or push. The user likely has commit signing and SSH credentials configured that won't work via shell commands.
+
+Tell the user to run these commands manually:
+
+```bash
+git add on-prem/VERSION on-prem/.env.example on-prem/CHANGELOG.md
+git commit -m "release: on-prem <version>"
+git push -u origin HEAD
+```
+
+Wait for the user to confirm they've committed and pushed, or re-run this command after they have.
+
+### 7. Create the PR (if needed)
+
+Once changes are pushed, check if a PR already exists using GitHub MCP `list_pull_requests` or `search_pull_requests`.
+
+If no PR exists, follow the `create-pull-request` command to create a PR with:
+
+- Title: `release: on-prem <version>`
+- Body: Summary of changes from the changelog
+
+## Notes
+
+- This command is idempotent — it can be run multiple times and will pick up where it left off
+- This command stops after creating the PR
+- CI will run validation and smoke tests on the PR
+- After CI passes and PR is merged, follow the tagging steps in the top-level README.md
+- See the Release Process in the top-level README.md for the complete workflow

.cursor/commands/update-pr-description.md

@@ -0,0 +1,4 @@
+Update the matching branch's pull request description in remote repository https://github.com/currents-dev/docker
+
+- read the existing description as previous vetted context, but check if recent code changes have invalidated the previous information
+- Use the same instructions and structure as appears in ./create-pull-request.md

.github/pull_request_template.md

@@ -0,0 +1,7 @@
+> Replace with a description
+
+## Checklist
+
+- [ ] PR title is Changelog-friendly: `(fix|feat|chore): title [CSR-xxx]`
+- [ ] User-friendly and meaningful description of the changes
+- [ ] Documentation was updated

README.md

@@ -29,34 +29,58 @@ Releases are tied to Currents container image tags, which use date-based version
 
 ### Release Process
 
-#### 1. Update the version
+> **Note:** `2026-01-14-001` is used as an example version throughout these steps. Replace it with the actual version you're releasing (format: `YYYY-MM-DD-NNN`).
+
+#### 1. Create a release branch
+
+```bash
+git checkout -b release-on-prem/2026-01-14-001
+```
+
+#### 2. Update the version
 
 Edit `on-prem/VERSION` and `on-prem/.env.example` with the image tag.
 
-#### 2. **Update the changelog** in `on-prem/CHANGELOG.md`
+#### 3. Update the changelog in `on-prem/CHANGELOG.md`
 
 - Move items from "Unreleased" to a new version section
 - Add release date and summary of changes
 
-#### 3. Commit the release
+#### 4. Commit and push the release branch
 
 ```bash
 git add on-prem/VERSION on-prem/.env.example on-prem/CHANGELOG.md
 git commit -m "release: on-prem 2026-01-14-001"
+git push -u origin HEAD
 ```
 
-#### 4. Create a git tag (namespaced for on-prem)
+#### 5. Create a PR and wait for CI
 
 ```bash
-git tag on-prem/2026-01-14-001
+gh pr create --title "release: on-prem 2026-01-14-001" --body "Release on-prem 2026-01-14-001"
 ```
 
-#### 5. Push
+CI will run validation and smoke tests. Wait for checks to pass, then get the PR reviewed and merged.
+
+#### 6. Tag the release from main
+
+> **Important:** Always tag from `main` after the PR is merged to ensure the tag points to the merged commit.
 
 ```bash
-git push && git push --tags
+git checkout main && git pull
+git tag on-prem/2026-01-14-001
+git push origin on-prem/2026-01-14-001
 ```
 
+#### 7. Create a GitHub release
+
+Create a release on GitHub for the tag:
+
+1. Go to [Releases](https://github.com/currents-dev/docker/releases/new)
+2. Select the tag `on-prem/2026-01-14-001`
+3. Set the title to `on-prem/2026-01-14-001`
+4. Add release notes linking to the CHANGELOG
+
 ### Tag Format
 
 Tags are namespaced by tool to allow for future additions:

on-prem/.env.example

@@ -53,7 +53,7 @@ GITLAB_STATE_SECRET=
 
 # Currents application images
 DC_CURRENTS_IMAGE_REPOSITORY=513558712013.dkr.ecr.us-east-1.amazonaws.com/currents/on-prem/
-DC_CURRENTS_IMAGE_TAG=staging
+DC_CURRENTS_IMAGE_TAG=2026-01-26-001
 
 # Application URLs
 APP_BASE_URL=http://localhost:4000

on-prem/CHANGELOG.md

@@ -6,6 +6,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [2026-01-26-001] - 2026-01-26
+
 ### Added
 - Initial public release
 - Docker Compose configuration with modular profiles (full, database, cache)

on-prem/VERSION

@@ -1 +1 @@
-staging
+2026-01-26-001