From 7c8f9d94058eafa2465bda502e70928fff1bd120 Mon Sep 17 00:00:00 2001 From: Jan Kadlec Date: Fri, 27 Feb 2026 15:57:37 +0100 Subject: [PATCH 1/2] fix(docs): fix version discovery to match three-part branch names The release branches use three-part versions (e.g. rel/1.60.0) but discover-versions.sh filtered with a two-part regex (major.minor), matching zero branches. Updated the regex to match three-part versions and strip the patch to get the section name (1.60), aligning with the original generate.sh behavior and docs/config/production/params.toml. jira: trivial risk: nonprod --- scripts/discover-versions.sh | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/scripts/discover-versions.sh b/scripts/discover-versions.sh index 0236a537a..ca7d6f382 100755 --- a/scripts/discover-versions.sh +++ b/scripts/discover-versions.sh @@ -10,20 +10,22 @@ num_versions=${2:-4} git fetch "$remote_name" 2>/dev/null -# Build a map of section -> branch, keeping only the latest minor per section. -# Associative arrays preserve last-write-wins semantics, matching the original -# generate.sh behavior where later branches overwrite earlier ones. +# Build a map of section -> branch, keeping only the latest patch per section. +# Branches are three-part versions (e.g. rel/1.60.0). We strip the patch to get +# the section (e.g. 1.60), matching the original generate.sh behavior where +# ${target_section%.*} strips the patch component. declare -A section_map declare -a section_order while IFS= read -r vers; do + # Strip patch: 1.60.0 -> 1.60 section="${vers%.*}" if [ -z "${section_map[$section]+x}" ]; then section_order+=("$section") fi - # Later (higher minor) versions overwrite earlier ones for the same major + # Later (higher patch) versions overwrite earlier ones for the same major.minor section_map["$section"]="rel/$vers" -done < <(git branch -rl "$remote_name/rel/*" | sed 's|.*/rel/||' | grep -E '^[0-9]+\.[0-9]+$' | sort -t. -k1,1n -k2,2n | tail -n"$num_versions") +done < <(git branch -rl "$remote_name/rel/*" | sed 's|.*/rel/||' | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n"$num_versions") # Add dev branch if it exists if git branch -rl "$remote_name/rel/dev" | grep -q "rel/dev"; then From d68a99a6a120ca5b42358ce803fa7c7fd69d40c4 Mon Sep 17 00:00:00 2001 From: Jan Kadlec Date: Fri, 27 Feb 2026 16:08:01 +0100 Subject: [PATCH 2/2] fix(docs): set HUGO_ENV=production explicitly in v2 workflow Without explicit HUGO_ENV=production, Hugo loads config/_default/params.toml which only has a single "Latest" entry. The full version list for the version picker lives in config/production/params.toml (maintained by bump_doc_dependencies.py during releases). Hugo defaults to production for builds, but being explicit matches the original hugo-build-versioned-action and avoids any ambiguity. jira: trivial risk: nonprod --- .github/workflows/netlify-deploy-v2.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/netlify-deploy-v2.yaml b/.github/workflows/netlify-deploy-v2.yaml index c0e8be1c5..241c352d5 100644 --- a/.github/workflows/netlify-deploy-v2.yaml +++ b/.github/workflows/netlify-deploy-v2.yaml @@ -124,6 +124,8 @@ jobs: restore-keys: hugo-resources- - name: Build documentation working-directory: ./docs + env: + HUGO_ENV: production run: hugo --minify --baseURL https://www.gooddata.com/docs/python-sdk - name: Publish (draft) uses: netlify/actions/cli@master