name: Compatibility

# The question this answers: *will the shop still work after I press update?*
#
# It runs on a schedule rather than on a commit, because the thing that breaks
# a finished plugin is not a new commit — it is a new WordPress or a new
# WooCommerce, released on somebody else's timetable. A weekly run turns that
# into a red build here, days before it turns into a broken checkout there.
#
# `nightly` and `beta` are the early warning: they are what the next release
# will be. When one of those two cells goes red and the others stay green, the
# plugin has a few weeks to be fixed rather than a few hours.

on:
  schedule:
    # Monday morning, so a failure has a whole week in front of it.
    - cron: '0 6 * * 1'
  workflow_dispatch:
  # Also whenever the tooling itself changes, because a compatibility run that
  # silently stopped testing anything is worse than no run at all.
  pull_request:
    paths:
      - 'ci/**'
      - 'tests/**'
      - '.github/workflows/compat.yml'
      - '.gitea/workflows/compat.yml'

permissions:
  contents: write
  pull-requests: write

# No `concurrency:` block — see the note in ci.yml. Kept byte-identical in
# .github/workflows and .gitea/workflows; ci/workflows-in-sync.sh enforces it.

jobs:
  matrix:
    name: WP ${{ matrix.wp }} / WC ${{ matrix.wc }} / PHP ${{ matrix.php }}
    # The schedule fires on both forges, and the second run would be the same
    # work again on a single self-hosted runner for no extra information.
    # GitHub's runners take the scheduled load; Gitea keeps workflow_dispatch,
    # so the run is still one click away there.
    if: github.event_name != 'schedule' || github.server_url == 'https://github.com'
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        include:
          # Today's shop.
          - { wp: latest,  wc: latest, php: '8.3' }
          # The next WordPress, before it ships.
          - { wp: nightly, wc: latest, php: '8.3' }
          # The next WooCommerce, before it ships. Falls back to the stable
          # release when there is no open beta, so the cell is never skipped.
          - { wp: latest,  wc: beta,   php: '8.3' }
          # The floor the plugin header promises. A shop on an old host is
          # exactly the shop that will not notice a fatal quickly.
          - { wp: latest,  wc: latest, php: '7.4' }
          # And the newest PHP, which is where deprecations show up first.
          - { wp: latest,  wc: latest, php: '8.4' }

    steps:
      - uses: actions/checkout@v4

      - name: Install into a throwaway shop and run the tests
        env:
          WP_VERSION: ${{ matrix.wp }}
          WC_VERSION: ${{ matrix.wc }}
          PHP_VERSION: ${{ matrix.php }}
        run: ci/site-test.sh

  headers:
    name: Keep the compatibility headers honest
    # Only after the current releases have actually been tested. Bumping
    # "Tested up to" on a red build would be writing a claim we have just
    # watched fail.
    needs: matrix
    # The PR is opened through the GitHub API, and the scheduled run that
    # produces it is the GitHub one.
    if: github.server_url == 'https://github.com' && github.event_name == 'schedule'
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Bump the headers and open a PR if they are behind
        env:
          GH_TOKEN: ${{ github.token }}
        run: ci/bump-tested-up-to.sh