Fix nightly builds to use chronological tag sorting instead of version sorting

[Copilot]

Nightly builds were being created unnecessarily by comparing against the wrong tag. Git's version sort treats v2.10.0-0 (prerelease) as greater than v2.10.0 (stable), causing the workflow to select tags based on version numbers rather than creation date.

Changes

Modified .github/workflows/GitFlow_Nightly-builds.yml to use chronological tag sorting instead of version-based sorting:

# Before: Selected tag by version number (incorrect for chronological comparison)
$LATEST_TAG = git tag -l --sort=-version:refname | Select-Object -First 1

# After: Select most recently created tag (stable or prerelease)
$LATEST_TAG = git tag -l --sort=-creatordate | Select-Object -First 1

Behavior

The workflow now correctly compares against the chronologically latest release, whether stable or prerelease:

• Latest stable (e.g., v2.9.0) → creates v2.9.1-0 (first prerelease)
• Latest prerelease (e.g., v2.9.1-1) → creates v2.9.1-2 (increment prerelease)
• No PRs merged since last release → skips build

This ensures that when a stable release (v2.9.1) is created after a prerelease (v2.9.1-0), the workflow correctly uses the stable release as the comparison point.

Original prompt

I need to review the way nightly builds are handled. They create nightly builds identical to the latest stable release even if there are no changes in between. Check the GitHub Actions to understand.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Romanitho]

@copilot I am giving you the log of the latest nightly action run (latest task should have been v2.9.1 instead of v2.9.1-0 and i think the problem is here.):

shell: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.EXE -command ". '{0}'"
env:
BRANCH: develop

Checking for new changes since last release

[INFO] Latest release tag: v2.9.1-0
[INFO] Previous tag is a prerelease -> using 'prerelease' to increment suffix

[AUTO] Scheduled nightly build - checking for changes...
[INFO] Tag creation date: 2025-12-15 15:11:39 +0000
[INFO] Tag commit SHA: a2f3a80
[INFO] Current branch: develop
[INFO] Current HEAD: 129842d

[INFO] Searching for merged PRs between a2f3a80 and HEAD...
[INFO] Found 3 merged PR(s)

[INFO] Merged PRs since last tag:

• 020b0dc Merge pull request Release 2.9.1 #1100 from Romanitho/release/2.9.1
• 2124332 Merge pull request Improve nightly build PR check and logging #1095 from Romanitho/fix/nightlies
• b28f7a8 Merge pull request Add default initialization for RELEASE_TYPE to handle edge cases #1097 from Romanitho/copilot/sub-pr-1095

[BUILD] Building new prerelease version (type: prerelease).

========================================
Build needed: True
Release type: prerelease

[Copilot]

@copilot I am giving you the log of the latest nightly action run (latest task should have been v2.9.1 instead of v2.9.1-0 and i think the problem is here.):

shell: C:\Windows\System32\WindowsPowerSh...

You're absolutely right - the workflow selected v2.9.1-0 (prerelease) instead of v2.9.1 (stable). This is exactly the bug my fix addresses.

The log you shared shows the OLD code running (notice the message "[INFO] Latest release tag" instead of "[INFO] Latest stable release tag"). This is because the nightly workflow runs on the develop branch and uses the workflow file from that branch. My fix hasn't been merged to develop yet.

Once this PR is merged, the workflow will:

1. Filter tags to separate stable (v2.9.1) from prerelease (v2.9.1-0)
2. Prioritize the stable tag v2.9.1 for comparison
3. Skip the build since develop HEAD matches the stable release commit

Commit: 98fc06b

[github-actions]

❌MegaLinter analysis: Error

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	1.62s
⚠️ REPOSITORY	checkov	yes		3	no	12.21s
⚠️ REPOSITORY	devskim	yes		1	8	1.42s
✅ REPOSITORY	dustilock	yes		no	no	0.01s
❌ REPOSITORY	gitleaks	yes		2	no	0.77s
✅ REPOSITORY	git_diff	yes		no	no	0.01s
✅ REPOSITORY	grype	yes		no	no	27.32s
✅ REPOSITORY	kics	yes		no	no	1.51s
✅ REPOSITORY	secretlint	yes		no	no	0.54s
✅ REPOSITORY	syft	yes		no	no	1.03s
✅ REPOSITORY	trivy	yes		no	no	7.12s
✅ REPOSITORY	trivy-sbom	yes		no	no	0.1s
✅ REPOSITORY	trufflehog	yes		no	no	2.2s

Detailed Issues

❌ REPOSITORY / gitleaks - 2 errors

Linter output file not found

⚠️ REPOSITORY / checkov - 3 errors

Linter output file not found

⚠️ REPOSITORY / devskim - 1 error

Linter output file not found

See detailed reports in MegaLinter artifacts
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

[Romanitho]

@copilot What I want: to be able to create nightly builds only if a new PR was merged on develop branch since the latest release (stable or pre-release). But I don't want nightly builds to run every night if there are no code changes. If the latest build is v2.9.0, I want v2.9.1-0, and if the latest is v2.9.1-1, I want v2.9.1-2. If there is no PR in between, the build should be skipped.

[Copilot]

@copilot What I want: to be able to create nightly builds only if a new PR was merged on develop branch since the latest release (stable or pre-release). But I don't want nightly builds to run every n...

Updated the fix to use chronological tag sorting (-creatordate) instead of version sorting. This ensures the workflow compares against the most recently created tag, whether it's stable or prerelease.

Now it works correctly:

• Latest stable (v2.9.0) → creates v2.9.1-0 ✓
• Latest prerelease (v2.9.1-1) → creates v2.9.1-2 ✓
• Skips build if no PRs merged since last release ✓

In your scenario, with v2.9.1-0 (Dec 15) and v2.9.1 (later), it will now correctly select v2.9.1 as the latest.

Commit: 4a9a8b2

[Copilot]

Pull request overview

This PR fixes a bug in the nightly build workflow where incorrect tag sorting caused unnecessary builds. The workflow was using --sort=-version:refname which incorrectly treated prerelease tags (e.g., v2.10.0-0) as greater than stable releases (e.g., v2.10.0), leading to comparisons against the wrong baseline tag.

Key Changes:

• Changed tag sorting from version-based (--sort=-version:refname) to chronological (--sort=-creatordate)
• Added clarifying comments explaining why chronological sorting is used
• Updated log message to reflect the change in sorting approach