refactor(scripts): improve version handling in build scripts by TimeToBuildBob · Pull Request #1280 · ActivityWatch/activitywatch

TimeToBuildBob · 2026-04-19T15:55:38Z

Summary

Replace hardcoded VERSION="0.1.0" in scripts/package/build_app_tauri.sh with a dynamic call to getversion.sh
Refactor getversion.sh to support multiple CI environments (GitHub Actions, Travis, AppVeyor) with a clean --strip-v flag
Use SCRIPT_DIR for robust relative path resolution in package-all.sh and package-deb.sh
Replace manual sed-based v-prefix stripping with --strip-v flag throughout
Add verbose version logging in CI workflows for easier debugging

Background

Salvaged from #1271 by @caoweiping (closed due to PR title issues). The changes themselves are clean and passed CI. Greptile rated them 4/5 confidence.

Changes

scripts/package/getversion.sh — refactored with multi-CI support and --strip-v flag
scripts/package/build_app_tauri.sh — dynamic version instead of hardcoded 0.1.0
scripts/package/package-all.sh — uses $SCRIPT_DIR and --strip-v
scripts/package/package-deb.sh — uses $SCRIPT_DIR and --strip-v
.github/workflows/build.yml — adds version logging step
.github/workflows/build-tauri.yml — adds version logging step

@caoweiping

- Replace hardcoded VERSION="0.1.0" in build_app_tauri.sh with dynamic getversion.sh call - Refactor getversion.sh to support multiple CI environments (GitHub Actions, Travis, AppVeyor) and add --strip-v flag - Use SCRIPT_DIR for robust relative path resolution in package scripts - Replace manual sed-based v-prefix stripping with --strip-v flag - Add verbose version logging in CI workflows for easier debugging Salvaged from ActivityWatch#1271 by @caoweiping.

greptile-apps · 2026-04-19T15:59:28Z

Greptile Summary

This PR refactors version-detection across the build scripts: getversion.sh gains a proper argument parser, --strip-v flag, and GitHub Actions (GITHUB_REF_NAME) support; callers switch from fragile $(dirname "$0") or hardcoded 0.1.0 to $SCRIPT_DIR-relative invocations; and CI workflows add a verbose logging step. The core improvements are solid and eliminate a real bug (hardcoded version in build_app_tauri.sh), with only minor style-level issues remaining.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style/cleanup suggestions that do not affect correctness.

The PR fixes a concrete bug (hardcoded version), improves path robustness, and adds CI visibility. All open comments are P2: unused GITHUB_ENV exports, double getversion.sh invocation, and an edge-case v* branch filter. None affect the primary use cases defined by the workflow triggers.

.github/workflows/build.yml and .github/workflows/build-tauri.yml — the new GITHUB_ENV exports are dead code and could be either removed or wired to replace the older VERSION_TAG fallback pattern in the Package dmg step.

Important Files Changed

Filename	Overview
scripts/package/getversion.sh	Refactored with structured argument parsing, `--strip-v` flag, and GitHub Actions support; `GITHUB_REF_NAME == v*` filter can match non-release branches.
scripts/package/package-deb.sh	Switched to `SCRIPT_DIR`-based path resolution and `--strip-v` flag; calls `getversion.sh` twice, running git operations redundantly.
scripts/package/package-all.sh	Replaced `$(dirname "$0")` with `$SCRIPT_DIR`, added `get_version_no_prefix` function — also invokes `getversion.sh` twice; removed inline `sed` v-strip in `build_setup`.
scripts/package/build_app_tauri.sh	Replaced hardcoded `VERSION="0.1.0"` with dynamic `getversion.sh --strip-v` call using `SCRIPT_DIR`; clean and correct.
.github/workflows/build.yml	New version-logging step exports `VERSION_WITH_V`/`VERSION_NO_V` to `GITHUB_ENV` but no downstream step consumes them; logging echoes are useful.
.github/workflows/build-tauri.yml	Same version-logging step added as `build.yml`; `VERSION_WITH_V`/`VERSION_NO_V` env exports are unused by subsequent steps.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CI / Local shell] --> B{Caller}
    B --> C[build_app_tauri.sh]
    B --> D[package-all.sh]
    B --> E[package-deb.sh]
    B --> F[GitHub Actions workflow step]

    C -->|SCRIPT_DIR/getversion.sh --strip-v| G[getversion.sh]
    D -->|get_version / get_version_no_prefix| G
    E -->|getversion.sh / getversion.sh --strip-v| G
    F -->|bash getversion.sh / getversion.sh --strip-v| G

    G --> H{CI env var?}
    H -->|GITHUB_REF_NAME starts with v| I[Use GITHUB_REF_NAME]
    H -->|TRAVIS_TAG set| J[Use TRAVIS_TAG]
    H -->|APPVEYOR_REPO_TAG_NAME set| K[Use APPVEYOR tag]
    H -->|None| L[git describe --exact-match]
    L -->|found| M[Release tag version]
    L -->|not found| N[latest-tag.dev-shortsha]

    I & J & K & M & N --> O{--strip-v?}
    O -->|yes| P[sed strip leading v]
    O -->|no| Q[Output as-is]
    P & Q --> R[echo version]

_{Reviews (1): Last reviewed commit: "refactor(scripts): improve version handl..." | Re-trigger Greptile}

greptile-apps · 2026-04-19T15:59:33Z

+        echo "VERSION_WITH_V=${VERSION_WITH_V}" >> $GITHUB_ENV
+        echo "VERSION_NO_V=${VERSION_NO_V}" >> $GITHUB_ENV


GITHUB_ENV exports appear unused downstream

VERSION_WITH_V and VERSION_NO_V are written to $GITHUB_ENV here, but no subsequent step in build.yml references ${{ env.VERSION_WITH_V }} or ${{ env.VERSION_NO_V }}. The existing Package dmg step (line 196) still falls back to its own VERSION_TAG:-$(scripts/package/getversion.sh) pattern. The echo logging is useful, but the env-var exports are dead code as written.

Consider either removing the >> $GITHUB_ENV lines or updating downstream steps to consume these variables (e.g., replacing ${VERSION_TAG:-$(scripts/package/getversion.sh)} with ${VERSION_WITH_V}).

Fixed in 89f8080: the Package dmg step now uses ${VERSION_WITH_V} (already exported to GITHUB_ENV by the version-logging step), eliminating the fallback getversion.sh call there.

greptile-apps · 2026-04-19T15:59:35Z

+          echo "VERSION_WITH_V=${VERSION_WITH_V}" >> $GITHUB_ENV
+          echo "VERSION_NO_V=${VERSION_NO_V}" >> $GITHUB_ENV


GITHUB_ENV exports appear unused downstream

Same pattern as build.yml — VERSION_WITH_V and VERSION_NO_V are exported to $GITHUB_ENV but no later step in build-tauri.yml consumes them. The Package dmg step at line 182 still uses the VERSION_TAG:-$(scripts/package/getversion.sh) fallback. If the intent is only debug logging, the >> $GITHUB_ENV lines can be dropped; if the intent is to consolidate version resolution, downstream steps should be updated to reference these new variables.

Fixed in 89f8080: same as build.yml — Package dmg now uses ${VERSION_WITH_V} from GITHUB_ENV.

greptile-apps · 2026-04-19T15:59:37Z

+    if [[ -n "$GITHUB_REF_NAME" && "$GITHUB_REF_NAME" == v* ]]; then
+        _version="$GITHUB_REF_NAME"


GITHUB_REF_NAME == v* can match non-release branch names

Any branch whose name starts with 'v' (e.g. v2-refactor, v-next) will satisfy the == v* glob and be used verbatim as the version string instead of falling through to git describe. In the workflows' defined triggers this is low-risk, but getversion.sh is a standalone utility callable outside those constraints.

A tighter guard using GITHUB_REF:

if [[ -n "$GITHUB_REF" && "$GITHUB_REF" == refs/tags/v* ]]; then _version="${GITHUB_REF_NAME}"

This matches only actual tag pushes, not branches that happen to start with 'v'.

Fixed in 89f8080: now checks $GITHUB_REF == refs/tags/v* instead of $GITHUB_REF_NAME == v*, so only actual tag pushes match.

greptile-apps · 2026-04-19T15:59:38Z

+VERSION="$("$SCRIPT_DIR/getversion.sh")"
+VERSION_NUM="$("$SCRIPT_DIR/getversion.sh" --strip-v)"


Double getversion.sh invocation runs git twice

getversion.sh is called twice back-to-back, each time running git describe (the hot path when no CI env var is set). The same pattern appears in package-all.sh via get_version / get_version_no_prefix. A single call and one sed strip would be cleaner:

VERSION="$("$SCRIPT_DIR/getversion.sh")" VERSION_NUM="$(echo "$VERSION" | sed -e 's/^v//')"

This also matches what --strip-v does internally, so no behavior change occurs.

Fixed in 89f8080: package-deb.sh now calls getversion.sh once and derives VERSION_NUM with sed -e 's/^v//'.

ErikBjare · 2026-04-19T17:42:11Z

@TimeToBuildBob Address greptile's nits

ErikBjare · 2026-04-19T18:39:04Z

@TimeToBuildBob why not responding?

- getversion.sh: tighten GITHUB_REF guard to refs/tags/v* to avoid matching v-prefixed branch names - package-deb.sh: call getversion.sh once, derive VERSION_NUM with sed (avoids double git-describe) - build.yml, build-tauri.yml: use VERSION_WITH_V env var in Package dmg step (wires up existing export, removes redundant getversion.sh call)

TimeToBuildBob · 2026-04-19T19:02:53Z

Addressed all 4 Greptile nits in 89f8080:

getversion.sh: tightened CI guard to $GITHUB_REF == refs/tags/v* (avoids matching v-prefixed branch names)
package-deb.sh: single getversion.sh call + sed for strip (no double git-describe)
build.yml / build-tauri.yml: Package dmg now uses ${VERSION_WITH_V} from GITHUB_ENV (makes the env export useful, removes the fallback getversion.sh call)

… env export VERSION_NO_V was computed via a second getversion.sh invocation but never used by any subsequent step — only echoed to build log. Switch to shell parameter expansion (${VERSION_WITH_V#v}) for zero-cost stripping, and drop the dead GITHUB_ENV export. Addresses Greptile P2 nits on ActivityWatch#1280.

TimeToBuildBob · 2026-04-23T03:30:26Z

Addressed all Greptile P2 nits:

Previously addressed (commit 89f8080):

getversion.sh: tightened GITHUB_REF guard to refs/tags/v*
package-deb.sh: single getversion.sh call, derive VERSION_NUM with sed
build.yml / build-tauri.yml: wired VERSION_WITH_V in Package dmg step

Just pushed (commit b37ee4e):

Both workflow "Determine and output version" steps: derive VERSION_NO_V via shell expansion ${VERSION_WITH_V#v} instead of a second getversion.sh invocation
Dropped unused VERSION_NO_V from $GITHUB_ENV (only VERSION_WITH_V is used by subsequent steps); it's still echoed in the build log for visibility

CI is green. Ready for merge when you are.

TimeToBuildBob · 2026-04-23T03:38:39Z

Update: the latest CI run failed due to a transient npm network error in the aw-webui build step (unrelated to this PR's changes):

npm error network In most cases you are behind a proxy or have bad network settings.
Error in aw-server build
Process completed with exit code 2.

The failure is in aw-server/aw-webui's npm install step, which my changes don't touch (this PR only modifies scripts in scripts/package/ and adds version logging to the workflow). Could a maintainer re-run CI?

greptile-apps Bot reviewed Apr 19, 2026

View reviewed changes

TimeToBuildBob mentioned this pull request Apr 20, 2026

perf(gptme-voice): skip context loading in fast subagent mode gptme/gptme-contrib#713

Merged

2 tasks

ci: retrigger CI (transient npm network failure)

1c2bb8a

ErikBjare merged commit 8301338 into ActivityWatch:master Apr 30, 2026
15 checks passed

		echo "VERSION_WITH_V=${VERSION_WITH_V}" >> $GITHUB_ENV
		echo "VERSION_NO_V=${VERSION_NO_V}" >> $GITHUB_ENV

		if [[ -n "$GITHUB_REF_NAME" && "$GITHUB_REF_NAME" == v* ]]; then
		_version="$GITHUB_REF_NAME"

		VERSION="$("$SCRIPT_DIR/getversion.sh")"
		VERSION_NUM="$("$SCRIPT_DIR/getversion.sh" --strip-v)"

Uh oh!

Conversation

TimeToBuildBob commented Apr 19, 2026

Summary

Background

Changes

Uh oh!

greptile-apps Bot commented Apr 19, 2026

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

greptile-apps Bot Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

TimeToBuildBob Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

TimeToBuildBob Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

TimeToBuildBob Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

TimeToBuildBob Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

ErikBjare commented Apr 19, 2026

Uh oh!

ErikBjare commented Apr 19, 2026

Uh oh!

TimeToBuildBob commented Apr 19, 2026

Uh oh!

TimeToBuildBob commented Apr 23, 2026

Uh oh!

TimeToBuildBob commented Apr 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants