merge stable - 1.5.10.2482 into dev #299
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name: Sync generated files and version | |
| # Merge-triggered trigger stub. All the logic lives in FOGProject/fog-workflows' | |
| # update-lang-fix-psr-and-sync-version.yml; this file exists only because GitHub | |
| # Actions has no cross-repo merge trigger, so something has to live here to react | |
| # to a merge. | |
| # | |
| # THIS IS THE ONLY THING THAT WRITES FOG_VERSION ON A MERGE, and since GH-1510 | |
| # it is the only thing that writes it on this branch at all outside the daily | |
| # sweep. .githooks/pre-commit used to stamp a version on every local commit; | |
| # that made every branch open at the same time hold a different value on the | |
| # same tracked line, so each merge left the others with a hand-resolved | |
| # conflict on system.class.php. Its header has the full reasoning. | |
| # | |
| # A client-side hook could not have covered this case anyway: a PR merged | |
| # through GitHub's web UI (squash, merge commit or rebase) runs no local hook, | |
| # so FOG_VERSION would go stale until the daily sweep fires at 10:10 UTC. This | |
| # closes that window. | |
| # | |
| # WHY `pull_request`, AND NOT `pull_request_target` | |
| # | |
| # `pull_request_target` looks like the right answer -- it is the variant that | |
| # gets secrets on fork PRs -- and the first version of this file used it. It | |
| # never fired once. GitHub reads a `pull_request_target` workflow from the | |
| # repository's DEFAULT branch (`stable` here), not from the PR's base branch, so | |
| # a copy living on working-1.6 and dev-branch is simply never consulted: the | |
| # workflow did not even appear in the Actions list, and four PRs merged into | |
| # working-1.6 without it running. | |
| # | |
| # `pull_request` is read from the base branch instead, so this file works where | |
| # it actually lives. Do not "fix" it back to `pull_request_target` without also | |
| # putting the file on `stable` -- and note that then only stable's copy would | |
| # execute, which makes editing the version on this branch a no-op. | |
| # | |
| # WHY NOT `push` | |
| # | |
| # That distinction is the whole safety argument, not caution. The sweep pushes | |
| # its fixup commit straight to the branch, and a direct push is not a PR merge, | |
| # so it cannot re-fire this stub. The 2026-07-28 runaway that put ~30 commits on | |
| # dev-branch in about 20 minutes was a push-triggered stub doing exactly that. | |
| # The schedule in fog-workflows stays exactly as it is, and remains the backstop | |
| # for direct pushes and for rc-*/feature-* branches. | |
| # | |
| # WHY THE SAME-REPO GUARD | |
| # | |
| # `pull_request` withholds secrets from fork PRs, and the reusable workflow needs | |
| # FOG_WORKFLOWS_PRIVATE_KEY to mint its App token -- so on a fork PR it would | |
| # fail rather than work. Skipping is right: a merged fork PR is picked up by the | |
| # daily sweep, exactly as a direct push already is. Better a gap the schedule | |
| # already covers than a red X on every external contribution. | |
| # | |
| # One file, identical on every branch that carries it, for the same reason | |
| # tests.yml is: fixing it should not mean editing it on three branches. Each | |
| # branch's copy only ever acts on merges into that branch, and the allowlist | |
| # below is what scopes it. | |
| on: | |
| pull_request: | |
| types: [closed] | |
| concurrency: | |
| group: fog-sync-on-merge-${{ github.event.pull_request.base.ref }} | |
| cancel-in-progress: false | |
| jobs: | |
| sync: | |
| # An allowlist, not "not stable". Branches cut from working-1.6 inherit this | |
| # file, and an rc-*/feature-* branch must NOT be merge-synced: fog-version.sh | |
| # reports drift on every run for rc (it increments off the committed suffix | |
| # rather than a commit count), so a per-merge sync would bump the RC suffix | |
| # on every merge. Those stay on the daily sweep. stable is excluded because | |
| # its version is owned entirely by fog-workflows' stable-releases.yml. | |
| # | |
| # `closed` fires on abandoned PRs too, hence the merged check -- and the | |
| # reusable workflow uses its `branch` input verbatim, with no validation | |
| # against its own watched list, so constraining it is this file's job. | |
| if: >- | |
| github.event.pull_request.merged == true | |
| && github.event.pull_request.head.repo.full_name == github.repository | |
| && contains(fromJson('["working-1.6", "dev-branch"]'), github.event.pull_request.base.ref) | |
| # Least privilege, stated rather than inherited. Everything the reusable | |
| # workflow writes -- the commit, the push, and the version badge -- uses a | |
| # GitHub App token, so nothing on this path needs a writable GITHUB_TOKEN. A | |
| # called workflow can never hold more permission than its caller, so leaving | |
| # this to the repo-wide default would make the effective permission whatever | |
| # that happens to be. See fos' create_release.yml for the same reasoning. | |
| permissions: | |
| contents: read | |
| uses: FOGProject/fog-workflows/.github/workflows/update-lang-fix-psr-and-sync-version.yml@main | |
| with: | |
| branch: ${{ github.event.pull_request.base.ref }} | |
| secrets: inherit |