ci: add GH action to validate that the contents of `latest` are identical to the contents of whatever the most recent tag is

[jdhoffa]

@john and I chatted about this in a DM on Teams, and I had a quick go at implementing it.
The following action should do the trick (assuming vX.Y.Z versioning. May need minor adjustments to account for timestamped versioning):

name: Validate Latest Schema

on:
  push:
    branches:
      - main
    paths:
      - 'releases/**'
  pull_request:
    branches:
      - main
    paths:
      - 'releases/**'

jobs:
  validate-latest-schema:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Identify highest version schema directory
        id: find-version
        run: |
          latest_version=$(ls schema/ | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n1)
          echo "latest_version=$latest_version" >> "$GITHUB_OUTPUT"
          echo "Latest version directory: $latest_version"

      - name: Compare latest to highest version
        run: |
          diff_output=$(diff -r schema/latest schema/${{ steps.find-version.outputs.latest_version }}) || (echo "$diff_output"; exit 1)
          echo "✅ 'latest' schema matches highest version: ${{ steps.find-version.outputs.latest_version }}"

[jdhoffa]

See it in action here:
https://github.com/jdhoffa/latest_version_demo

In this PR, we see a failure because the contents of latest are NOT identical to the contents of the highest version number directory:
https://github.com/jdhoffa/latest_version_demo/pull/3

In this PR, we see it pass, because even though the contents of latest are updated, they are updated identically to that of the highest version number directory:
https://github.com/jdhoffa/latest_version_demo/pull/4

While not strictly necessary, this is a nice fail-safe to ensure nobody accidentally forgets to keep latest in line with the last release. 😊

[john]

@jdhoffa I love this, thank you! I have limited (read: no) experience deploying Actions. What's the effort level to implement this? Once implemented, it would run every time a PR was submitted, and disallow merge until it passed?

[jdhoffa]

No sweat! Probably like ~5-10min to implement, the code above basically does the trick, just need to amend it slightly for the YYYY-MM-DD versioning/ timestamping that it seems like is happening in this repo.

Once that PR is merged, it will just run the action on every PR, and show the result of the status check at the bottom of the PR, but won't inherently disallow anything.

Deciding if you want that to allow/disallow merge is handled in the "Settings" of the repo, in branch protections.

Another thing to note, since this repository is public, the GH action minutes for running this won't incur any charges. If this repo ever becomes private, that would change, just food for thought.

[jdhoffa]

Anyway, gimme a 👍 on this comment if you want me to ahead and open a PR with this, and I can do so tomorrow in my morning

[jdhoffa]

#4 implements this status check.

Note: I have not added any branch protections to main, so merging to main would still be allowed even if the check fails.

Given that I am not involved with this repo at all, I don't feel comfortable personally mucking around it's Settings or branch protections.

But to do so, one simply needs to:

Go to Settings:

Make a new branch protection:

Target the default branch (this automatically targets main):

Ensure that status checks are enabled AND select the newly created validate-latest-release check:

[jdhoffa]

Closing as stale given that latest is no longer a relevant demarcation here