Rebuild scoped Rector after a pull request is merged

[TomasVotruba]

Merging a rule pull request here changes rectorphp/rector only once something else lands in rector-src main and retriggers its build. This dispatches that build directly instead.

New .github/workflows/dispatch_build_scoped_rector.yaml:

on:
    pull_request:
        types:
            - closed

jobs:
    dispatch_build_scoped_rector:
        # only for merged pull requests in this repository, not forks
        if: github.event.pull_request.merged == true && github.repository == 'rectorphp/rector-phpunit'

        runs-on: ubuntu-latest

        steps:
            -
                name: "Trigger build_scoped_rector.yaml in rectorphp/rector-src"
                env:
                    GH_TOKEN: ${{ secrets.ACCESS_TOKEN }}
                run: gh workflow run build_scoped_rector.yaml --repo rectorphp/rector-src --ref main

pull_request: closed fires on every close, so the merged == true check is what limits it to merges. Closed-without-merge dispatches nothing. Reuses the ACCESS_TOKEN secret already used by rector.yaml.

Merge rectorphp/rector-src#8188 first

build_scoped_rector.yaml has no workflow_dispatch trigger today, so gh workflow run returns HTTP 422 until rectorphp/rector-src#8188 lands. This pull request is inert but red on its own.

Two things to verify before merging

ACCESS_TOKEN needs actions: write on rectorphp/rector-src. rector.yaml only uses it to push to this repository, so cross-repository scope is unconfirmed — worth one manual gh workflow run against rector-src with that token.

The dispatch fires at merge time, but the build resolves rector-phpunit dev-main through Packagist, which can lag a merge by a few minutes. A dispatched build may rebuild against the previous main. A Packagist update hook on this repository is the fix; not included here.

[samsonasik]

If latest commit in rector-src is a release tag, rebuild should not be allowed as it will fail due to retagging

[TomasVotruba]

Good point!