Fix CI manual tag versioning to use tag creation date

[Arlodotexe]

Summary

Fixes issue where manually created tags produce packages with incorrect dates. Tag release/weekly/251027 (created 10/27) was producing packages dated 251021 (6-day mismatch).

Root Cause

The CI workflow used git log -1 --format=%cd without a tag reference, which extracts the commit date instead of the date from the tag name for tagged builds.

Changes

Tag Builds (Fixed)

• Now extracts date directly from tag name using string replacement: refs/tags/release/weekly/YYMMDD → YYMMDD
• Only sets VERSION_DATE environment variable for tag builds
• Allows intentional back-dating or post-dating of releases by using the date in the tag name
• Example: Tag refs/tags/release/weekly/251027 → packages dated 251027

Non-Tag Builds (Main/PR - No Change)

• VERSION_DATE environment variable is not set
• Build script defaults to current date via (Get-Date -UFormat %y%m%d)
• Behavior unchanged: packages are dated by build time

Build Script Invocation

• -DateForVersion parameter now conditionally passed only when VERSION_DATE is set
• Uses GitHub Actions expression: ${{ env.VERSION_DATE != '' && format('-DateForVersion {0}', env.VERSION_DATE) || '' }}

Implementation

- name: Format Date/Time for Package Version (Tag builds only)
  if: ${{ startsWith(github.ref, 'refs/tags/') }}
  run: |
    # Extract date from tag name (e.g., refs/tags/release/weekly/251027 -> 251027)
    # Non-tag builds: VERSION_DATE not set, script defaults to current date
    $dateString = "${{ github.ref }}" -replace '^refs/tags/release/weekly/', ''
    echo "VERSION_DATE=$dateString" >> $env:GITHUB_ENV

Rationale

Extracting from the tag name (rather than tag creation timestamp) allows for intentional back-dating or post-dating of releases, matching the pattern used in the main CommunityToolkit/Windows repository for rel/* branches.

[michael-hawker]

@Arlodotexe also don't forget to remove the chron job from the other workflow for now too.

[Arlodotexe]

@Arlodotexe also don't forget to remove the chron job from the other workflow for now too.

Since we know the scheduled job can't trip a build even though it creates a tag, should we just remove the job entirely?

[michael-hawker]

@Arlodotexe I suppose so at this point, worst case we have it in the history.

[michael-hawker]

LTGM