fix(RELEASE-1910): timing issue in promotion report generation

[happybhati]

Describe your changes

Fix timing issue in promotion report generation

Problem: Report generation fails after promotion because both branches become identical, resulting in "No commits found" error.

Solution: Capture commit range before promotion and use pre-captured data for report generation after promotion succeeds.

Changes:

• Add commit capture step before promotion
• Add --commit-range parameter to script
• Add error handling to prevent workflow failure
• Add manual recovery instructions

Relevant Jira

Checklist before requesting a review

• I have marked as draft or added do not merge label if there's a dependency PR
  • If you want reviews on your draft PR, you can add reviewers or add the release-service-maintainers handle if you are unsure who to tag
• My commit message includes Signed-off-by: My name <email>
• I read CONTRIBUTING.MD and commit formatting
• I have run the README.md generator script in .github/scripts/readme_generator.sh and verified the results using .github/scripts/check_readme.sh

[elenagerman]

I assume there is no Jira opened for this fix.
Could you please clarify in more detail what problem this MR will solve?
Is it a race condition? new merge during promotion procedure?

[happybhati]

I assume there is no Jira opened for this fix. Could you please clarify in more detail what problem this MR will solve? Is it a race condition? new merge during promotion procedure?

Hi Elena,
You're correct that there's no JIRA for this fix. This PR addresses a timing issue we discovered during yesterday's promotion.

The Problem:

• The original implementation had a race condition where:

• Promotion happens first (staging → production)

• Both branches become identical after promotion

• Report generation runs after promotion but finds no commits because both branches point to the same commit

The Solution:

• This PR captures the commit range before promotion and uses that pre-captured data for report generation after promotion succeeds.

Since this was a quick fix for an immediate issue, I didn't create a JIRA. Would you like me to create one for better tracking? I can create one quickly.

[happybhati]

@elenagerman updated the title and description and added the Jira as requested.

[elenagerman]

shouldn't it be COMMITS instead of COMMIT_RANGE?

Suggested change

	python .github/scripts/generate_promotion_report.py $FROM_BRANCH $TO_BRANCH --commit-range "$COMMIT_RANGE"
	python .github/scripts/generate_promotion_report.py $FROM_BRANCH $TO_BRANCH --commit-range "$COMMITS"

[happybhati]

Hi Elena,

No, we should use COMMIT_RANGE here. Here's why:

• COMMIT_RANGE = origin/production..origin/staging (git range format)
• COMMITS = multi-line list of individual commit hashes

The script's get_commits_with_diff() method expects a git range format (e.g., origin/production..origin/staging) to work with the git log command.

The COMMITS variable is stored primarily for reference and potential future use in manual recovery scenarios, but the script uses the range format for automated execution.

[elenagerman]

@elenagerman updated the title and description and added the Jira as requested.

Thanks a lot! Now it's all much clearer