Skip to content

ci: add backport labels automatically when a new minor version is released #6615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 13, 2025
Merged

ci: add backport labels automatically when a new minor version is released #6615

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 71 additions & 1 deletion .github/workflows/release-branch-create.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -153,8 +153,78 @@ jobs:
echo "EOF"
} >> $GITHUB_OUTPUT

- name: Post summary
- name: Ensure release labels
if: steps.check_version.outputs.is_minor_bump == 'true'
env:
GH_TOKEN: ${{ secrets.PR_GH_TOKEN || secrets.GITHUB_TOKEN }}
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[security] high Priority

Issue: Secrets are potentially exposed via environment variables with fallback pattern
Context: Using secrets.PR_GH_TOKEN || secrets.GITHUB_TOKEN pattern can leak token usage in logs
Suggestion: Use explicit conditional logic or ensure proper token scoping with minimal permissions

run: |
set -euo pipefail
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[quality] medium Priority

Issue: Inconsistent error handling pattern
Context: Some operations use set -euo pipefail while others use manual error checking
Suggestion: Apply consistent error handling throughout the script or document why different patterns are used


BRANCH_BASE="${{ steps.check_version.outputs.branch_base }}"

if [[ -z "$BRANCH_BASE" ]]; then
echo "::error::Branch base not set; unable to manage labels"
exit 1
fi

declare -A COLORS=(
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[quality] medium Priority

Issue: Hardcoded color values in associative array without validation
Context: Colors 4361ee and 4f6ef5 are not validated and may be inconsistent with design system
Suggestion: Extract colors to constants or validate hex format with proper error handling

[core]="4361ee"
[cloud]="4f6ef5"
)

for PREFIX in core cloud; do
LABEL="${PREFIX}/${BRANCH_BASE}"
COLOR="${COLORS[$PREFIX]}"
DESCRIPTION="Backport PRs for ${PREFIX} ${BRANCH_BASE}"

if gh label view "$LABEL" >/dev/null 2>&1; then
gh label edit "$LABEL" \
--color "$COLOR" \
--description "$DESCRIPTION"
echo "🔄 Updated label $LABEL"
else
gh label create "$LABEL" \
--color "$COLOR" \
--description "$DESCRIPTION"
echo "✨ Created label $LABEL"
fi
done

MIN_LABELS_TO_KEEP=3
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[quality] low Priority

Issue: Magic numbers used without clear reasoning
Context: MIN_LABELS_TO_KEEP=3 and MAX_LABELS_TO_FETCH=200 are hardcoded without explanation
Suggestion: Add inline comments explaining these thresholds or make them configurable via environment variables

MAX_LABELS_TO_FETCH=200

for PREFIX in core cloud; do
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[architecture] low Priority

Issue: Missing conditional execution guard for label cleanup
Context: Label cleanup runs even if label creation fails, potentially causing inconsistent state
Suggestion: Add error handling and only run cleanup if label creation succeeds

mapfile -t LABELS < <(
gh label list \
--json name \
--limit "$MAX_LABELS_TO_FETCH" \
--jq '.[].name' |
grep -E "^${PREFIX}/[0-9]+\.[0-9]+$" |
Copy link
Contributor

@DrJKL DrJKL Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use --search?

Copy link
Contributor

@DrJKL DrJKL Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also --sort=created maybe

sort -t/ -k2,2V
)

TOTAL=${#LABELS[@]}

if (( TOTAL <= MIN_LABELS_TO_KEEP )); then
echo "ℹ️ Nothing to prune for $PREFIX labels"
continue
fi

REMOVE_COUNT=$((TOTAL - MIN_LABELS_TO_KEEP))

if (( REMOVE_COUNT > 1 )); then
Copy link

@claude claude bot Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[quality] medium Priority

Issue: Label deletion logic has potential off-by-one errors
Context: The pruning logic limits removal to 1 when REMOVE_COUNT > 1, but this might not maintain proper ordering
Suggestion: Review deletion logic to ensure oldest labels are properly removed and consider sorting by semantic version

REMOVE_COUNT=1
Copy link
Contributor

@DrJKL DrJKL Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete 1 per run?

fi

for ((i=0; i<REMOVE_COUNT; i++)); do
OLD_LABEL="${LABELS[$i]}"
gh label delete "$OLD_LABEL" --yes
echo "🗑️ Removed old label $OLD_LABEL"
done
done

- name: Post summary
if: always() && steps.check_version.outputs.is_minor_bump == 'true'
run: |
CURRENT_VERSION="${{ steps.check_version.outputs.current_version }}"
RESULTS="${{ steps.create_branches.outputs.results }}"
Expand Down