Merge pull request #5 from pyTooling/claude/pipeline-and-release

Rename the workflow to 'Pipeline.yml' and release from it

Author: Paebbels

.github/workflows/Verification.yml .github/workflows/Pipeline.yml.github/workflows/Verification.yml renamed to .github/workflows/Pipeline.yml

@@ -15,13 +15,19 @@
 # WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
 # COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
 # OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-name: Verification of the Synchronize Forks Action
+name: Pipeline
+run-name: ${{ github.ref_type == 'tag' && github.ref_name || '' }}
 
 on:
   push:
+  # 'TagReleaseCommit' dispatches this workflow on the tag it created; a tag pushed by the automatic GITHUB_TOKEN
+  # doesn't trigger a workflow on its own.
   workflow_dispatch:
 
 jobs:
+  Prepare:
+    uses: pyTooling/Actions/.github/workflows/PrepareJob.yml@r8
+
   DryRun:
     name: 🐧 Dry-run with a valid configuration
     runs-on: ubuntu-26.04
@@ -128,3 +134,35 @@ jobs:
             printf "::error title=%s::%s\n" "FailOnError" "The action's outcome is '${OUTCOME}', but 'failure' was expected."
             exit 1
           fi
+
+  # A merge commit on 'main' is a release: tag it with the release pull-request's title and start this pipeline again
+  # on that tag.
+  TriggerTaggedRelease:
+    uses: pyTooling/Actions/.github/workflows/TagReleaseCommit.yml@r8
+    needs:
+      - Prepare
+      - DryRun
+      - ErrorHandling
+      - FailOnError
+    if: needs.Prepare.outputs.is_release_commit == 'true'
+    permissions:
+      contents: write   # required to create the tag
+      actions:  write   # required to start the tagged pipeline
+    with:
+      version:  ${{ needs.Prepare.outputs.version }}
+      auto_tag: ${{ needs.Prepare.outputs.is_release_commit }}
+    secrets: inherit
+
+  # The tagged run publishes the release page. Its description is the body of the pull-request that produced the
+  # tagged merge commit, which 'PublishReleaseNotes' looks up itself.
+  ReleasePage:
+    uses: pyTooling/Actions/.github/workflows/PublishReleaseNotes.yml@r8
+    needs:
+      - Prepare
+      - DryRun
+      - ErrorHandling
+      - FailOnError
+    if: needs.Prepare.outputs.is_release_tag == 'true'
+    with:
+      tag: ${{ needs.Prepare.outputs.version }}
+    secrets: inherit

README.md

@@ -1,4 +1,4 @@
-[![GitHub Workflow - Build and Test Status](https://img.shields.io/github/actions/workflow/status/pyTooling/SynchronizeForks/.github%2Fworkflows%2FVerification.yml?branch=dev&logo=githubactions)](https://GitHub.com/pyTooling/SynchronizeForks/actions/workflows/Verification.yml)
+[![GitHub Workflow - Build and Test Status](https://img.shields.io/github/actions/workflow/status/pyTooling/SynchronizeForks/.github%2Fworkflows%2FPipeline.yml?branch=dev&logo=githubactions)](https://GitHub.com/pyTooling/SynchronizeForks/actions/workflows/Pipeline.yml)
 [![Sourcecode License](https://img.shields.io/badge/code-MIT%20License-green?longCache=true&style=flat-square&logoColor=fff)](LICENSE.md)
 
 # Synchronize Forks
@@ -288,6 +288,25 @@ fields are worth a look while converting: `<upstream>` is reported in the progre
 placeholder there makes the log name the wrong repository, and adding tag patterns is what stops the fork from drifting
 behind in releases.
 
+## Pipeline
+
+[`Pipeline.yml`](.github/workflows/Pipeline.yml) runs the action against the fixtures in `tests/` in dry-run mode —
+three jobs, no token, no repository touched. Beyond that it releases itself, with reusable workflows from
+[pyTooling/Actions](https://github.com/pyTooling/Actions):
+
+* **`PrepareJob.yml`** classifies the run — which branch or tag, a regular or a merge commit, a release commit or a
+  release tag — so the two jobs below know whether they apply.
+* **`TagReleaseCommit.yml`** turns a merge commit on `main` into a tag named after the release pull-request's title
+  (`v1.0.0`), and starts this pipeline again on that tag. A tag pushed with the automatic `GITHUB_TOKEN` doesn't
+  trigger a workflow, which is why the pipeline is dispatched explicitly — and why this file has to be called
+  `Pipeline.yml`.
+* **`PublishReleaseNotes.yml`** runs on the tagged pipeline, once the same three jobs pass, and publishes the release
+  page. Its description is the body of the pull-request that produced the tagged merge commit; the workflow finds that
+  pull-request from the merge commit itself.
+
+So a release is one merge: open a `dev` → `main` pull-request titled `vMM.mm.pp`, write the release notes in its
+description, and merge it.
+
 ## Dependencies
 
 * [GitHub CLI (`gh`)](https://cli.github.com/), pre-installed on GitHub-hosted runners.

tests/README.md

@@ -1,6 +1,6 @@
 # Test Fixtures
 
-Configuration files used by [`Verification.yml`](../.github/workflows/Verification.yml). The action is run in dry-run
+Configuration files used by [`Pipeline.yml`](../.github/workflows/Pipeline.yml). The action is run in dry-run
 mode against them, so no repository is synchronized and no token is needed.
 
 * `Valid` — one organisation, one commented out organisation, four repositories of which one is commented out, and