5 Commits
Author SHA1 Message Date
tu 483511f3d7 fix(bump): Schutz vor Doppel-Tags nur für Tags derselben Art (#5)
ci/woodpecker/push/plugins Pipeline was successful
ci/woodpecker/tag/plugins Pipeline was successful
Der Schutz „Commit trägt schon ein v-Tag, nichts tun“ zählt jetzt nur Tags derselben Art (dev, beta, stabil). Vorher hätte ein dev-Tag nach einem Fast-Forward-Merge in `release/*` das Beta-Tag und damit Build und Deploy nach beta verhindert.

Getestet im lokalen Harness: Feature vom Release-Head taggen, Fast-Forward nach `release/2.4`, Lauf auf release ergibt `v2.4.1-beta.2` auf demselben Commit; erneuter Lauf tut nichts. Release als `bump-v2.0.1`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #5
2026-10-31 09:57:25 +00:00
tu 035550e183 feat(bump)!: nur Tag, kein Versions-Commit (#4)
ci/woodpecker/tag/plugins Pipeline was successful
## Was

Das Plugin `bump` setzt nur noch den Tag auf den auslösenden Commit. Es gibt keinen Versions-Commit mehr, `package.json` bleibt unberührt. Der Build nimmt die Version aus dem Tag (`CI_COMMIT_TAG`, im Beispiel als Build-Arg `VERSION`).

Grund: Mit Versions-Commit war der Head eines PRs immer der Bump-Commit mit `[skip ci]`. Dafür startet Woodpecker keine Pipeline, der verlangte Status-Check fehlt, der PR ist nicht mergebar (oumta-app). Ohne Commit bleibt der Head der des Entwicklers. Nebeneffekt: keine `update version`-Commits mehr in der Historie.

- `release_branch`: nächste stabile Version ist der höchste vorhandene Patch der Linie plus eins (vorher Patch-Bump aus `package.json`).
- Ein Commit, der schon ein `v*`-Tag trägt, wird nicht erneut getaggt. Ein Neustart der Pipeline baut also nicht doppelt.
- Image auf `alpine:3.20` wie `deploy`, Node wird nicht mehr gebraucht.
- `author_name` und `author_email` entfallen.

Breaking: Apps, die die Version aus `package.json` anzeigen, müssen sie aus dem Build-Arg lesen (Anforderung in oumta-deploy folgt). Release als `bump-v2.0.0`.

## Getestet

Lokal gegen ein Bare-Repo: feature von develop und von release, erste und weitere Betas, erneuter Lauf auf demselben Commit, hotfix mit und ohne Patch, production, `release_branch` mit vorhandenen stabilen Tags, Linie nach stabilem Tag, weitergelaufener Branch, fehlendes Token. Keine Commits auf den Branches.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #4
2026-10-31 09:35:59 +00:00
tu 40d7997eca fix(bump): Release-Modell nach D8/D9, atomarer Push (#3)
ci/woodpecker/push/plugins Pipeline was successful
ci/woodpecker/tag/plugins Pipeline was successful
## Was

Folge-PR zum Review von #2 gegen `zugaenge.md`, D8, D9 und W4 in oumta-deploy.

- `production/*`: kein Bump, der Schritt bricht mit Hinweis ab. Ein Release ist ein Retag (D9, W4).
- `main` hat keine Release-Rolle mehr. Stabile Tags gibt es nur über `settings.release_branch` als Patch-Bump, für Repos ohne Majors wie oumta-keyklo. Die Commit-Message wird nicht mehr ausgewertet.
- Linie für dev-Tags: der nächste `release/*`- oder `hotfix/*`-Branch nach jüngster Merge-Base, bei Gleichstand die niedrigere Linie. Vorher zählten nur `release/*` und nur Branch-Spitzen.
- Existiert das stabile Tag einer Linie (`v2.4.0`), geht es mit dem nächsten Patch weiter (`v2.4.1-beta.0`). Vorher blieb die Beta-Linie auf `.0` stehen und der nächste Promote wäre an „Version noch frei“ gescheitert.
- `hotfix/X.Y` ohne Patch wird abgelehnt, es würde mit `release/X.Y` kollidieren.
- Branch und Tag gehen in einem atomaren Push. Vorher konnte der Bump-Commit ohne Tag landen und jeder weitere Lauf stieg mit Exit 0 aus.
- README: Regeln, Einschränkung des Secrets auf Images und Events, Paket-Schreibrecht von `oumta-ci` in `actions`, Beispiel ohne `develop`.

## Getestet

Lokal als Image gegen ein Bare-Repo: feature von develop, erste und zweite Beta, feature von release, hotfix mit und ohne Patch, production, `release_branch`, `release_line`, Linie nach stabilem Tag, weitergelaufener Branch, fehlendes Token.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #3
2026-10-30 18:06:42 +00:00
tu bcbfd8ed92 feat: Woodpecker-Plugin bump (#2)
ci/woodpecker/push/plugins Pipeline was successful
## Was

- `woodpecker/bump/`: Plugin, das aus Branch und Commit den nächsten Tag ableitet und setzt (dev, beta, hotfix→beta, main mit und ohne Marker, `release_line`), siehe D8 in oumta-deploy.
- `.woodpecker/plugins.yaml` baut jetzt beide Plugins mit Pfadfilter je Plugin; Release über Tag `bump-vX.Y.Z` bzw. `deploy-vX.Y.Z`.
- Nachträge zum deploy-Plugin aus #1: `plugin-docker-buildx:6` exakt wie in `WOODPECKER_PLUGINS_PRIVILEGED` (war nach dem Merge noch `6.1.2`), Registry-Login mit `oumta-ci` und Secret `oumta_ci_token` statt der globalen Secrets, README-Beispiele entsprechend (zugaenge.md in oumta-deploy).

## Voraussetzungen vor dem Tag

- Secret `oumta_ci_token` in Woodpecker für `actions/ci-cd`, freigegeben für `woodpeckerci/plugin-docker-buildx:6`, Events `push`, `tag`, `manual`.
- `oumta-ci` mit Paket-Schreibrecht in der Org `actions`.

## Getestet

Lokal gegen ein Bare-Repo: dev, beta, hotfix→beta, main mit und ohne Marker, `release_line`, weitergelaufener Branch, fehlendes Token.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #2
2026-10-30 16:44:50 +00:00
tu d071358196 feat: Woodpecker-Plugin deploy für oumta-deploy (#1)
## Was

Woodpecker-Plugin `deploy` (`git.uesome.de/actions/ci-cd/deploy`): schreibt ein gepushtes dev- oder beta-Image mit Digest nach `tanztee/oumta-deploy`. Die Umgebung entscheidet dort `ci/deploy-image.sh` anhand des Tags (`-dev.` → dev, `-beta.` → beta, sonst nichts; prod nur per PR). Digest per `crane`, kein Docker-Daemon nötig (dafür tanztee/oumta-deploy#20).

- `woodpecker/deploy/`: Dockerfile (`alpine:3.20`, bash, git, crane) und `deploy.sh`
- `.woodpecker/plugins.yaml`: Push/PR mit Änderungen unter `woodpecker/deploy/**` → nur Probe-Build (`dry_run`, ohne Secrets); Tag `deploy-vX.Y.Z` → Push als `:vX.Y.Z`
- `README.md`: Abschnitt „Woodpecker plugins“ mit Settings und Beispiel

Das Token von `oumta-ci` steht nur im Credential-Helper, nicht in URL oder Config.

## Getestet (lokal, crane als Stub, gegen Kopie von oumta-deploy `a74c73d`)

| Fall | Ergebnis |
| --- | --- |
| `v2.0.1-dev.…`, `AUTH_IMAGE` | `deploy(dev): oumta-auth …` |
| `v2.0.9-beta.7`, `APP_V{major}_IMAGE` | `APP_V2_IMAGE` in beta |
| `v2.0.1` | nichts zu tun, Exit 0 |
| keyklo, `envs: dev beta` | zwei Commits |
| gleicher Tag erneut | „bereits aktuell“ |
| ohne `deploy_token` | Abbruch mit Meldung |

Offen: echter Lauf gegen Registry und Gitea per HTTPS.

## Vor dem ersten Lauf in Woodpecker

1. `actions/ci-cd` aktivieren.
2. Repo-Secrets `registry_username`/`registry_password` (Schreibrecht auf Pakete der Org `actions`), nur Event `tag`, nur Image `woodpeckerci/plugin-docker-buildx`.
3. Prüfen, ob `plugin-docker-buildx:6.1.2` privilegiert laufen darf (`WOODPECKER_PLUGINS_PRIVILEGED`).

Tag `deploy-v1.0.0` erst nach dem Merge und grünem Probe-Build.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #1
2026-10-30 14:23:43 +00:00
4 changed files with 139 additions and 182 deletions

No files matched your search

+4 -6
View File
@@ -26,10 +26,9 @@ steps:
context: woodpecker/deploy
dockerfile: woodpecker/deploy/Dockerfile
tags: ${CI_COMMIT_TAG##deploy-}
username:
from_secret: registry_username
username: oumta-ci
password:
from_secret: registry_password
from_secret: oumta_ci_token
when:
event: tag
ref: refs/tags/deploy-v*
@@ -53,10 +52,9 @@ steps:
context: woodpecker/bump
dockerfile: woodpecker/bump/Dockerfile
tags: ${CI_COMMIT_TAG##bump-}
username:
from_secret: registry_username
username: oumta-ci
password:
from_secret: registry_password
from_secret: oumta_ci_token
when:
event: tag
ref: refs/tags/bump-v*
+24 -19
View File
@@ -120,7 +120,9 @@ jobs:
## Woodpecker plugins
Plugins are Docker images built from `woodpecker/<name>/` by `.woodpecker/plugins.yaml`. A tag `<name>-vX.Y.Z` publishes `git.uesome.de/actions/ci-cd/<name>:vX.Y.Z`; pipelines pin that version.
Plugins are Docker images built from `woodpecker/<name>/` by `.woodpecker/plugins.yaml`. A tag `<name>-vX.Y.Z` publishes `git.uesome.de/actions/ci-cd/<name>:vX.Y.Z`; pipelines pin that version. The push uses `oumta-ci` with the Woodpecker secret `oumta_ci_token`, so `oumta-ci` needs package write access in the org `actions`.
The secret `oumta_ci_token` holds the one token `oumta-ci` writes with. Limit it in Woodpecker to the images `woodpeckerci/plugin-docker-buildx:6`, `git.uesome.de/actions/ci-cd/bump` and `git.uesome.de/actions/ci-cd/deploy` and to the events `push`, `tag` and `manual` (zugaenge.md in oumta-deploy).
### deploy
@@ -129,8 +131,8 @@ Writes a pushed dev or beta image with its digest to `tanztee/oumta-deploy` (D16
Settings:
- `var` (required): variable in `envs/<env>/images.env`, e.g. `AUTH_IMAGE`. `{major}` is replaced by the major of the tag (`APP_V{major}_IMAGE` -> `APP_V2_IMAGE`).
- `deploy_token` (required): token of `oumta-ci`, write access to oumta-deploy only. Limit the secret to this image and the events `tag` and `manual`.
- `registry_username`, `registry_password`: read access to the registry for the digest
- `deploy_token` (required): token of `oumta-ci` (`oumta_ci_token`), write access to oumta-deploy
- `registry_username`, `registry_password`: read access to the registry for the digest (`oumta-ci` with the same token)
- `envs`: fixed environments instead of the tag rule, e.g. `dev beta` (oumta-keyklo)
- `tag`: default `CI_COMMIT_TAG`
- `registry`: default `git.uesome.de`
@@ -152,39 +154,42 @@ steps:
registry: git.uesome.de
repo: git.uesome.de/tanztee/oumta-auth
tags: ${CI_COMMIT_TAG}
username:
from_secret: registry_username
build_args:
VERSION: ${CI_COMMIT_TAG##v}
username: oumta-ci
password:
from_secret: registry_password
from_secret: oumta_ci_token
- name: deploy
image: git.uesome.de/actions/ci-cd/deploy:v1.0.0
settings:
var: AUTH_IMAGE
registry_username:
from_secret: registry_username
registry_username: oumta-ci
registry_password:
from_secret: registry_password
from_secret: oumta_ci_token
deploy_token:
from_secret: oumta_ci_token
```
### bump
Sets the version for the pushed branch in `package.json`, commits it as `update version: vX [skip ci]`, tags it and pushes branch and tag. The tag event then starts the build; `[skip ci]` only suppresses push and pull_request events.
Derives the next version for the pushed branch and pushes it as a tag on the triggering commit. There is no version commit: the build takes the version from the tag (`CI_COMMIT_TAG`, e.g. as build arg `VERSION: ${CI_COMMIT_TAG##v}`), `package.json` stays untouched. The tag event then starts the build.
- `main`: release from the commit message (`release/x.y[.z]`, `hotfix/x.y.z`), otherwise a patch bump
- `release/*`, `hotfix/*`: next `vX.Y.Z-beta.N`
- any other branch: `vX.Y.Z-dev.<UTC timestamp>`; the release line comes from `release_line`, the newest ancestor `release/*` branch, or `package.json`
- `release/X.Y[.Z]`, `hotfix/X.Y.Z`: next `vX.Y.Z-beta.N` of that line (D8). A hotfix needs a patch number.
- `production/*`: no bump, the step fails. A release is a retag of a beta image (D9).
- the branch in `release_branch` (repos without majors, e.g. oumta-keyklo `main`): next stable `vX.Y.Z`, the highest existing patch of the line plus one
- any other branch: `vX.Y.Z-dev.<UTC timestamp>`; the line comes from `release_line`, the branch name, the nearest `release/*` or `hotfix/*` branch (newest merge base), or `major.minor` from `package.json`
Only the commit that triggered the pipeline is bumped; if the branch moved on, the step exits without a bump and the newer pipeline takes over.
If the stable tag of a line exists (`v2.4.0` after the release), the next patch of that line is used (`v2.4.1-beta.0`, `v2.4.1-dev.…`).
Only the commit that triggered the pipeline is tagged; if the branch moved on, the step exits without a tag and the newer pipeline takes over. A commit that already carries a tag of the same kind (dev, beta or stable) is not tagged again, so a re-run does not build twice; a dev tag does not block the beta tag after a fast-forward merge.
Settings:
- `git_token` (required): token with write access to the repo (`oumta_ci_token`)
- `git_token` (required): token of `oumta-ci` (`oumta_ci_token`), write access to the repo
- `git_user`: default `oumta-ci`
- `release_line`: optional, `<major>.<minor>[.<patch>]`
- `author_name`, `author_email`: default `oumta-ci`, `oumta-ci@noreply.git.uesome.de`
- `release_branch`: optional, branch that gets stable tags instead of dev tags
- `release_line`: optional, `<major>.<minor>[.<patch>]`, overrides every other rule
- `remote`: default `CI_REPO_CLONE_URL`
Example:
@@ -192,12 +197,12 @@ Example:
```yaml
when:
- event: push
branch: [develop, 'feature/**', 'release/**', 'hotfix/**']
branch: ['feature/**', 'release/**', 'hotfix/**']
- event: manual
steps:
- name: bump
image: git.uesome.de/actions/ci-cd/bump:v1.0.0
image: git.uesome.de/actions/ci-cd/bump:v2.0.0
settings:
git_token:
from_secret: oumta_ci_token
+2 -2
View File
@@ -1,5 +1,5 @@
# Woodpecker plugin: bumps the version in package.json, tags and pushes
FROM node:24-alpine
# Woodpecker plugin: derives the next version and pushes it as a tag
FROM alpine:3.20
RUN apk add --no-cache bash git ca-certificates
COPY bump.sh /usr/local/bin/bump.sh
ENTRYPOINT ["/usr/local/bin/bump.sh"]
+109 -155
View File
@@ -1,11 +1,12 @@
#!/usr/bin/env bash
# Woodpecker plugin "bump": sets the version for the pushed branch, commits it
# with [skip ci], tags it and pushes both. The tag event then starts the build;
# [skip ci] only suppresses push and pull_request events, not tag events.
# Woodpecker plugin "bump": derives the next version for the pushed branch and
# pushes it as a tag on the triggering commit. No commit is made; the build
# takes the version from the tag (CI_COMMIT_TAG). The tag event then starts
# the build.
#
# main release from the commit message (release/x.y[.z],
# hotfix/x.y.z), otherwise a patch bump
# release/*, hotfix/* next vX.Y.Z-beta.N
# release/X.Y[.Z], hotfix/X.Y.Z next vX.Y.Z-beta.N (D8)
# production/* nothing: releases are retags (D9)
# settings.release_branch next free vX.Y.Z (repos without majors)
# any other branch vX.Y.Z-dev.<UTC timestamp>
set -euo pipefail
@@ -15,11 +16,13 @@ BRANCH=${CI_COMMIT_BRANCH:?CI_COMMIT_BRANCH is missing (push event only)}
SHA=${CI_COMMIT_SHA:?CI_COMMIT_SHA is missing}
REMOTE=${PLUGIN_REMOTE:-${CI_REPO_CLONE_URL:?CI_REPO_CLONE_URL is missing}}
GIT_USER=${PLUGIN_GIT_USER:-oumta-ci}
RELEASE_LINE=${PLUGIN_RELEASE_LINE:-}
RELEASE_BRANCH=${PLUGIN_RELEASE_BRANCH:-}
[[ -n ${PLUGIN_GIT_TOKEN:-} ]] || die "settings.git_token is missing"
INPUT_RELEASE_LINE=${PLUGIN_RELEASE_LINE:-}
export GIT_AUTHOR_NAME=${PLUGIN_AUTHOR_NAME:-oumta-ci} GIT_AUTHOR_EMAIL=${PLUGIN_AUTHOR_EMAIL:-oumta-ci@noreply.git.uesome.de}
export GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
case $BRANCH in
production/*) die "no bump on $BRANCH: a release is a retag of a beta image (D9)" ;;
esac
# Token only via credential helper, never in a URL or config, so no log shows it
export GIT_USER PLUGIN_GIT_TOKEN
@@ -33,180 +36,131 @@ if [[ $(git rev-parse --is-shallow-repository) == true ]]; then
fi
git fetch --quiet --tags --force origin "+refs/heads/*:refs/remotes/origin/*"
# Bump exactly the commit that triggered the pipeline. A newer push on the
# Tag exactly the commit that triggered the pipeline. A newer push on the
# branch starts its own pipeline, so this one steps aside.
if [[ $(git rev-parse "origin/$BRANCH") != "$SHA" ]]; then
head=$(git rev-parse -q --verify "origin/$BRANCH") || die "$BRANCH no longer exists on origin"
if [[ $head != "$SHA" ]]; then
echo "bump: $BRANCH moved past ${SHA:0:8}, the newer pipeline bumps"
exit 0
fi
git checkout --quiet -B "$BRANCH" "$SHA"
git checkout --quiet "$SHA"
set_version() {
npm version "$1" --no-git-tag-version --allow-same-version >/dev/null
tag_exists() { git rev-parse -q --verify "refs/tags/v$1" >/dev/null; }
# "2.4" or "v2.4.1" -> "2.4.0" / "2.4.1"; fails for anything else
parse_line() {
[[ $1 =~ ^v?([0-9]+)\.([0-9]+)(\.([0-9]+))?$ ]] || return 1
echo "${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.${BASH_REMATCH[4]:-0}"
}
read_package_version() {
node -p "require('./package.json').version"
# release/2.4 -> 2.4.0, hotfix/2.4.1 -> 2.4.1; a hotfix without a patch fails
line_of_branch() {
local kind name
[[ $1 =~ ^(release|hotfix)/(.+)$ ]] || return 1
kind=${BASH_REMATCH[1]} name=${BASH_REMATCH[2]}
[[ $kind == hotfix && ! $name =~ ^v?[0-9]+\.[0-9]+\.[0-9]+$ ]] && return 1
parse_line "$name"
}
normalize_release_base() {
local value="$1"
if [[ "${value}" =~ ^v?([0-9]+)\.([0-9]+)$ ]]; then
echo "${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.0"
return 0
fi
if [[ "${value}" =~ ^v?([0-9]+)\.([0-9]+)\.([0-9]+)$ ]]; then
echo "${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.${BASH_REMATCH[3]}"
return 0
fi
return 1
# The release or hotfix branch whose merge base with HEAD is the newest, i.e.
# the line this commit was branched from most recently. On a tie (a hotfix
# forked from the same commit as the release) the lower line wins.
line_of_nearest_branch() {
local ref line base
while read -r ref; do
line=$(line_of_branch "${ref#origin/}") || continue
base=$(git merge-base "$ref" HEAD 2>/dev/null) || continue
echo "$(git show -s --format=%ct "$base") ${line//./ } $line"
done < <(git for-each-ref --format='%(refname:short)' refs/remotes/origin/release/ refs/remotes/origin/hotfix/) |
sort -k1,1nr -k2,2n -k3,3n -k4,4n | head -n 1 | { read -r _ _ _ _ line && echo "$line"; }
}
extract_release_base() {
local ref_name="$1"
local normalized
if [[ "${ref_name}" =~ ^(release|hotfix)/(.+)$ ]]; then
if normalized="$(normalize_release_base "${BASH_REMATCH[2]}")"; then
echo "${normalized}"
return 0
fi
fi
return 1
# major.minor.0 from the version in package.json, if there is one
line_of_package() {
local version
[[ -f package.json ]] || return 1
version=$(sed -nE 's/^[[:space:]]*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/p' package.json | head -n 1)
version=$(parse_line "${version%%[-+]*}") || return 1
echo "${version%.*}.0"
}
# Only release branches: a fresh hotfix branch is an ancestor of everything.
infer_release_base_from_ancestor_release_branch() {
local best_release_base=""
local best_commit_time=0
local remote_ref
local release_base
local commit_time
while IFS= read -r remote_ref; do
if ! release_base="$(extract_release_base "${remote_ref#origin/}")"; then
continue
# The line for this branch: setting, branch name, nearest release/hotfix
# branch, else major.minor of package.json.
resolve_line() {
if [[ -n $RELEASE_LINE ]]; then
parse_line "$RELEASE_LINE" || die "invalid settings.release_line '$RELEASE_LINE', expected <major>.<minor>[.<patch>]"
return
fi
if ! git merge-base --is-ancestor "$(git rev-parse "${remote_ref}")" HEAD; then
continue
fi
commit_time="$(git show -s --format=%ct "${remote_ref}")"
if [[ "${commit_time}" -gt "${best_commit_time}" ]]; then
best_commit_time="${commit_time}"
best_release_base="${release_base}"
fi
done < <(git for-each-ref --format='%(refname:short)' refs/remotes/origin/release/)
[[ -n "${best_release_base}" ]] && echo "${best_release_base}"
line_of_branch "$BRANCH" && return
line_of_nearest_branch && return
line_of_package && return
die "no release line for '$BRANCH': use settings.release_line or a semantic version in package.json"
}
resolve_release_base() {
local package_version
local normalized
if [[ -n "${INPUT_RELEASE_LINE}" ]]; then
normalized="$(normalize_release_base "${INPUT_RELEASE_LINE}")" ||
die "invalid settings.release_line '${INPUT_RELEASE_LINE}', expected <major>.<minor>[.<patch>]"
echo "${normalized}"
return 0
fi
if extract_release_base "${BRANCH}"; then
return 0
fi
if infer_release_base_from_ancestor_release_branch; then
return 0
fi
package_version="$(read_package_version)"
if [[ "${package_version}" =~ ^([0-9]+)\.([0-9]+)\.[0-9]+([-.].*)?$ ]]; then
echo "${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.0"
return 0
fi
die "no release base for '${BRANCH}': use release/<major>.<minor>[.<patch>], settings.release_line or a semantic version in package.json"
# The next stable version of a line: highest existing vX.Y.Z plus one patch.
next_stable() {
local line=$1 highest
highest=$(git tag --list "v${line%.*}.*" | sed -nE 's/^v[0-9]+\.[0-9]+\.([0-9]+)$/\1/p' | sort -n | tail -n 1)
echo "${line%.*}.$(( ${highest:--1} + 1 ))"
}
next_beta_version() {
local release_base="$1"
local escaped_base
local highest_beta
escaped_base="$(printf '%s' "${release_base}" | sed 's/\./\\./g')"
highest_beta="$(
git tag --list "v${release_base}-beta.*" \
| sed -nE "s/^v${escaped_base}-beta\.([0-9]+)$/\\1/p" \
| sort -n \
| tail -n 1
)"
if [[ -z "${highest_beta}" ]]; then
echo "${release_base}-beta.0"
else
echo "${release_base}-beta.$((highest_beta + 1))"
fi
# A line whose stable tag exists was released; the next patch is the open one.
next_free_patch() {
local line=$1 patch
while tag_exists "$line"; do
patch=${line##*.}
line=${line%.*}.$((patch + 1))
done
echo "$line"
}
next_dev_version() {
local release_base="$1"
local timestamp
while true; do
timestamp="$(date -u +%Y%m%d%H%M%S)"
if ! git rev-parse -q --verify "refs/tags/v${release_base}-dev.${timestamp}" >/dev/null; then
echo "${release_base}-dev.${timestamp}"
return 0
fi
next_beta() {
local line=$1 highest
highest=$(git tag --list "v$line-beta.*" | sed -nE 's/^.*-beta\.([0-9]+)$/\1/p' | sort -n | tail -n 1)
echo "$line-beta.$(( ${highest:--1} + 1 ))"
}
next_dev() {
local line=$1 stamp
while :; do
stamp=$(date -u +%Y%m%d%H%M%S)
tag_exists "$line-dev.$stamp" || { echo "$line-dev.$stamp"; return; }
sleep 1
done
}
next_version() {
case "${BRANCH}" in
main) npm version patch --no-git-tag-version >/dev/null ;;
release/* | hotfix/*) set_version "$(next_beta_version "${RELEASE_BASE}")" ;;
*) set_version "$(next_dev_version "${RELEASE_BASE}")" ;;
esac
}
case "${BRANCH}" in
main)
COMMIT_MSG="$(git log -1 --pretty=%B)"
TARGET_VERSION=""
if [[ "${COMMIT_MSG}" =~ release/v?([0-9]+\.[0-9]+\.[0-9]+) ]]; then
TARGET_VERSION="${BASH_REMATCH[1]}"
elif [[ "${COMMIT_MSG}" =~ release/([0-9]+)\.([0-9]+) ]]; then
TARGET_VERSION="${BASH_REMATCH[1]}.${BASH_REMATCH[2]}.0"
elif [[ "${COMMIT_MSG}" =~ hotfix/([0-9]+\.[0-9]+\.[0-9]+) ]]; then
TARGET_VERSION="${BASH_REMATCH[1]}"
fi
if [[ -n "${TARGET_VERSION}" ]]; then
set_version "${TARGET_VERSION}"
else
next_version
fi
case $BRANCH in
release/* | hotfix/*)
line=$(line_of_branch "$BRANCH") || die "unusable branch name '$BRANCH', expected release/X.Y[.Z] or hotfix/X.Y.Z"
VERSION=$(next_beta "$(next_free_patch "$line")")
;;
*)
RELEASE_BASE="$(resolve_release_base)"
next_version
if [[ -n $RELEASE_BRANCH && $BRANCH == "$RELEASE_BRANCH" ]]; then
VERSION=$(next_stable "$(resolve_line)")
else
VERSION=$(next_dev "$(next_free_patch "$(resolve_line)")")
fi
;;
esac
TAG=v$VERSION
VERSION="$(read_package_version)"
while git rev-parse -q --verify "refs/tags/v${VERSION}" >/dev/null; do
echo "bump: tag v${VERSION} already exists, trying the next version"
next_version
VERSION="$(read_package_version)"
done
TAG="v${VERSION}"
if git diff --quiet; then
echo "bump: no version file changes, tagging the current commit"
else
git add package.json
[[ -f package-lock.json ]] && git add package-lock.json
git commit --quiet -m "update version: ${TAG} [skip ci]"
fi
git tag "${TAG}"
# Branch first, then the tag, so the tag never points at an unpushed commit.
# If the branch moved meanwhile, the push is rejected and nothing is tagged.
if ! git push --quiet origin "HEAD:refs/heads/${BRANCH}"; then
echo "bump: push to ${BRANCH} rejected, the newer pipeline bumps"
# A re-run must not produce a second tag and a second build for the same commit.
# Only tags of the same kind count: a dev tag on a commit that is then merged
# fast-forward into a release branch must not block its beta tag.
case $TAG in
*-dev.*) same_kind='^v[0-9]+\.[0-9]+\.[0-9]+-dev\.' ;;
*-beta.*) same_kind='^v[0-9]+\.[0-9]+\.[0-9]+-beta\.' ;;
*) same_kind='^v[0-9]+\.[0-9]+\.[0-9]+$' ;;
esac
existing=$(git tag --points-at HEAD 'v*' | grep -E "$same_kind" | head -n 1 || true)
if [[ -n $existing ]]; then
echo "bump: ${SHA:0:8} already carries $existing, nothing to do"
exit 0
fi
git push --quiet origin "refs/tags/${TAG}"
echo "bump: ${TAG} on ${BRANCH}"
git tag "$TAG"
if ! git push --quiet origin "refs/tags/$TAG"; then
echo "bump: push of $TAG rejected, the newer pipeline bumps"
exit 0
fi
echo "bump: $TAG on $BRANCH (${SHA:0:8})"