apify-test-tools 0.9.1-beta.8 → 0.9.1-beta.9

package/.github/actions/checkout-restore-dependencies/action.yaml

@@ -26,7 +26,7 @@ outputs:
 
 # Sets common steps and ensure we use cached node_modules
 # To test a change here, repoint the `uses:` refs in the reusable workflows at your branch, and
-# change them back before merging. Merging to master no longer ships it: consumers track the `v0`
+# change them back before merging. Merging to master no longer ships it: consumers track the `workflows-v0`
 # tag, which only moves once the package version in .github/workflows-package-version is on npm.
 runs:
     using: 'composite'

package/.github/scripts/check-major-tag-refs.mjs

@@ -36,7 +36,7 @@ const walk = (rel) => {
 
 const problems = [];
 
-// Self-references, e.g. `uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@v0`.
+// Self-references, e.g. `uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@workflows-v0`.
 // The ref charset stops at a backtick or quote so a ref quoted in prose isn't captured with its
 // punctuation; git refnames cannot end in a dot, so a sentence-final one is trimmed.
 const SELF_REF = /apify\/apify-test-tools\/\.github\/\S*?@([A-Za-z0-9._/-]+)/g;

package/.github/workflows/_move_major_tag.yaml

@@ -32,16 +32,24 @@ jobs:
             contents: write
         env:
             # The major version consumers pin, e.g.
-            # `uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@v0`.
+            # `uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@workflows-v0`.
             # Bump this only for a breaking change to a workflow's inputs, secrets or behaviour.
             # The previous tag then stops moving and keeps working, so repos migrate when they get
             # to it instead of all at once.
             #
             # This tracks the workflows' own contract, not the npm package version — the two move
-            # independently by design, so `v0` here is expected to outlive the package reaching 1.0.
+            # independently by design, so this is expected to outlive the package reaching 1.0.
+            #
+            # Deliberately not a bare `v0`. The package releases as `v0.9.0`, `v0.8.6` and so on, and
+            # a bare major tag sits in that same namespace: git-cliff hard-errors on it
+            # ("unexpected character 'v' while parsing major version number") and only skips it
+            # because apify/actions ships `tag_pattern = "v[0-9]+\\."`, whose trailing dot excludes
+            # it. Depending on a regex in another repo to keep releases working is not a dependency
+            # worth having, and `v1` beside a package `v1.0.0` would be worse still.
+            #
             # `uses:` cannot take an expression, so every ref into this repo hardcodes this same tag;
             # check-major-tag-refs.mjs fails the build if one of them drifts.
-            MAJOR_TAG: v0
+            MAJOR_TAG: workflows-v0
         steps:
             - name: Checkout repository
               uses: actions/checkout@v6

package/.github/workflows/public_platform-tests-claude-investigate-and-fix.yaml

@@ -20,7 +20,7 @@ name: 'Platform tests: Claude failure investigation and fix'
 #
 # jobs:
 #     platformTestsCore:
-#         uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@v0
+#         uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@workflows-v0
 #         with:
 #             subtest: core
 #         secrets: inherit
@@ -28,7 +28,7 @@ name: 'Platform tests: Claude failure investigation and fix'
 #     handle-failure:
 #         needs: platformTestsCore
 #         if: ${{ failure() }}
-#         uses: apify/apify-test-tools/.github/workflows/public_platform-tests-claude-investigate-and-fix.yaml@v0
+#         uses: apify/apify-test-tools/.github/workflows/public_platform-tests-claude-investigate-and-fix.yaml@workflows-v0
 #         secrets: inherit
 
 on:

package/.github/workflows/public_platform-tests.yaml

@@ -37,7 +37,7 @@ jobs:
         steps:
             - name: Setup repository and dependencies
               # For testing, you have to temporarily change the branch
-              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@v0
+              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@workflows-v0
               with:
                   working-directory: ${{ inputs.working-directory }}
                   additional-working-directory: ${{ inputs.additional-working-directory }}

package/.github/workflows/public_pr-build-test.yaml

@@ -35,7 +35,7 @@ jobs:
             - name: Setup repository and dependencies
               id: setup
               # For testing, you have to temporarily change the branch
-              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@v0
+              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@workflows-v0
               with:
                   working-directory: ${{ inputs.working-directory }}
                   additional-working-directory: ${{ inputs.additional-working-directory }}
@@ -142,7 +142,7 @@ jobs:
         steps:
             - name: Setup repository and dependencies
               # For testing, you have to temporarily change the branch
-              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@v0
+              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@workflows-v0
               with:
                   working-directory: ${{ inputs.working-directory }}
                   additional-working-directory: ${{ inputs.additional-working-directory }}

package/.github/workflows/public_push-build-latest.yaml

@@ -32,7 +32,7 @@ jobs:
             - name: Setup repository and dependencies
               id: setup
               # For testing, you have to temporarily change the branch
-              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@v0
+              uses: apify/apify-test-tools/.github/actions/checkout-restore-dependencies@workflows-v0
               with:
                   working-directory: ${{ inputs.working-directory }}
                   additional-working-directory: ${{ inputs.additional-working-directory }}

package/.github/workflows/public_review.yaml

@@ -14,7 +14,7 @@ on:
                 description: Label added after a successful review and never removed. Set to an empty string to disable.
                 required: false
             prompt-ref:
-                default: v0
+                default: workflows-v0
                 type: string
                 description: >-
                     Ref of this repository to fetch the review instructions from. Defaults to the

package/CHANGELOG.md

@@ -14,6 +14,10 @@ All notable changes to this project will be documented in this file.
 
 - Apply default actor timeout to runs ([#134](https://github.com/apify/apify-test-tools/pull/134)) ([82f5f7d](https://github.com/apify/apify-test-tools/commit/82f5f7d4de990db7ad8edf940c19ffd6b20bad13)) by [@Patai5](https://github.com/Patai5)
 
+### 🚜 Refactor
+
+- **workflows:** [**breaking**] Rename the floating tag to workflows-v0 ([#146](https://github.com/apify/apify-test-tools/pull/146)) ([c48fb22](https://github.com/apify/apify-test-tools/commit/c48fb223c885c4e5de7e5f64d8c14f6d03fcc7de)) by [@metalwarrior665](https://github.com/metalwarrior665)
+
 
 <!-- git-cliff-unreleased-end -->
 ## [0.9.0](https://github.com/apify/apify-test-tools/releases/tag/v0.9.0) (2026-08-11)

package/CONTRIBUTING.md

@@ -71,14 +71,20 @@ this repo's own triggers.
 A `public_` filename is part of the contract — it is baked into every consumer's `uses:` line, so
 renaming one is a breaking change that needs a major tag bump, not a tidy-up.
 
-Consumers pin `@v0`, not `@master`. See
+The tag is not semver, so `git-cliff` would abort on it. It is skipped only because
+`apify/actions`' cliff.toml sets `tag_pattern = "v[0-9]+\."` — a release failing with
+`Semver error: unexpected character` means that pattern changed, not that anything here is wrong.
+The action's "Nothing to release" guard resolves to this tag and no longer fires, so an empty stable
+release fails at `npm publish` instead of erroring cleanly.
+
+Consumers pin `@workflows-v0`, not `@master`. See
 [Versioning and releases](./README.md#versioning-and-releases) in the README for how the tag and the
 npm release relate — the short version:
 
 - changing only a workflow needs no npm release
 - changing only the package needs no workflow change
 - a workflow that calls a **new** CLI feature must set `.github/workflows-package-version` to the
-  version that will contain it, in the same PR. The `v0` tag is then held until that version is on
+  version that will contain it, in the same PR. The `workflows-v0` tag is then held until that version is on
   npm, so merging can't ship a workflow that calls a CLI that doesn't exist yet.
 
 `.github/workflows-package-version` holds one exact version, and the stable release writes it. The
@@ -99,5 +105,5 @@ pushing workflow changes.
 
 `public_review` is the odd one out: it fetches `.github/review-prompt.md` over HTTP at run time, because a
 reusable workflow runs with the caller's repo checked out and never gets its own. Its `prompt-ref`
-input defaults to `v0` so the instructions come from the same release as the workflow — leaving it
+input defaults to `workflows-v0` so the instructions come from the same release as the workflow — leaving it
 at `master` would run released workflows against unreleased instructions.

package/README.md

@@ -101,7 +101,7 @@ See the [GitHub workflows](#github-worklows) section below.
 
 The reusable workflows live in this repo, alongside the package they call. They are the
 `public_`-prefixed files in `.github/workflows`; everything else there is this repo's own CI.
-Reference them at the `@v0` major tag, never at `@master` — see
+Reference them at the `@workflows-v0` major tag, never at `@master` — see
 [Versioning and releases](#versioning-and-releases).
 
 There should be 4 GH workflow files in `.github/workflows`, plus an optional fifth for Claude reviews.
@@ -119,7 +119,7 @@ on:
 
 jobs:
     platformTestsCore:
-        uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@v0
+        uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@workflows-v0
         with:
             subtest: core
         secrets: inherit
@@ -138,7 +138,7 @@ on:
 
 jobs:
     platformTestsDaily:
-        uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@v0
+        uses: apify/apify-test-tools/.github/workflows/public_platform-tests.yaml@workflows-v0
         secrets: inherit
 ```
 
@@ -153,7 +153,7 @@ on:
 
 jobs:
     buildDevelAndTest:
-        uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@v0
+        uses: apify/apify-test-tools/.github/workflows/public_pr-build-test.yaml@workflows-v0
         secrets: inherit
 ```
 
@@ -168,7 +168,7 @@ on:
 
 jobs:
     buildLatest:
-        uses: apify/apify-test-tools/.github/workflows/public_push-build-latest.yaml@v0
+        uses: apify/apify-test-tools/.github/workflows/public_push-build-latest.yaml@workflows-v0
         secrets: inherit
 ```
 
@@ -186,13 +186,13 @@ on:
 
 jobs:
     review:
-        uses: apify/apify-test-tools/.github/workflows/public_review.yaml@v0
+        uses: apify/apify-test-tools/.github/workflows/public_review.yaml@workflows-v0
         secrets: inherit
 ```
 
 The review instructions live in `.github/review-prompt.md` in this repo and are fetched at run time,
 because a reusable workflow doesn't get its own repo checked out. `prompt-ref` selects which ref to
-fetch them from and defaults to `v0`, so the instructions match the workflow you're calling — point
+fetch them from and defaults to `workflows-v0`, so the instructions match the workflow you're calling — point
 it at a branch only to test a prompt change.
 
 ### Secrets
@@ -256,7 +256,7 @@ decide what a consumer repo actually runs:
 
 | Pointer                             | What it selects                                | Moves when                                               |
 | ----------------------------------- | ---------------------------------------------- | -------------------------------------------------------- |
-| the `@v0` tag in `uses:`            | which workflows run                            | a master push, once the version below is published       |
+| the `@workflows-v0` tag in `uses:`  | which workflows run                            | a master push, once the version below is published       |
 | `.github/workflows-package-version` | which `apify-test-tools` the workflows install | a stable release writes it; you may set it ahead of time |
 
 The setup action installs that **exact** version — not a range. A tag is therefore a complete
@@ -270,31 +270,33 @@ action, which is how branch testing works.
 
 Nothing is coupled that doesn't need to be:
 
-- **Workflow-only change** — merge it. `v0` moves, it goes live, no release needed.
+- **Workflow-only change** — merge it. `workflows-v0` moves, it goes live, no release needed.
 - **Package-only change** — merge it, then cut a release when you want it out. The workflows are
   unchanged, so consumers see nothing until the release lands.
 - **A workflow that calls a new CLI feature** — the one case that can break consumers, and the only
   one with any ceremony. Put the package change, the workflow change, and the new pin in one PR. On
-  merge the tag is **held**: the CI job reports that the pinned version isn't on npm and leaves `v0`
+  merge the tag is **held**: the CI job reports that the pinned version isn't on npm and leaves `workflows-v0`
   where it is, so consumers keep running the previous workflows. Cut a stable release, and the tag
   moves on its own. Run **Move major version tag** if you don't want to wait for the next master
   push.
 
-`v0` moving on every master push means `@v0` is as live as `@master` was — there's no staging step,
-just a gate on the package version. What the tag buys you is a `v1` for breaking workflow changes,
-so repos migrate one at a time instead of all at once, and a way to roll back by pointing the tag at
-an earlier commit. Bump `MAJOR_TAG` in `.github/workflows/_move_major_tag.yaml` to cut the next
-major; the old tag then freezes where it is and keeps working.
+`workflows-v0` moving on every master push means `@workflows-v0` is as live as `@master` was —
+there's no staging step, just a gate on the package version. What the tag buys you is a
+`workflows-v1` for breaking workflow changes, so repos migrate one at a time instead of all at once,
+and a way to roll back by pointing the tag at an earlier commit. Bump `MAJOR_TAG` in
+`.github/workflows/_move_major_tag.yaml` to cut the next major; the old tag then freezes where it is
+and keeps working.
 
-Freezing is real, which is the whole reason the version is pinned rather than a floor. A frozen `v0`
+Freezing is real, which is the whole reason the version is pinned rather than a floor. A frozen `workflows-v0`
 points at a commit whose pinned version never changes, so it keeps installing the library it was
 tested against no matter how far the package moves on. Had the workflows installed `>=<floor>`, a
-frozen `v0` would still resolve to whatever is newest — and since the release that enables `v1` is
-usually the same release that breaks `v0`, the migration window would have been zero.
+frozen `workflows-v0` would still resolve to whatever is newest — and since the release that enables
+`workflows-v1` is usually the same release that breaks `workflows-v0`, the migration window would
+have been zero.
 
 The tag tracks the **workflows'** contract, not the npm package version. They move independently on
-purpose, so `@v0` is expected to stay `@v0` after the package reaches 1.0 — bump it when a workflow
-breaks its callers, not when the package does. Because `uses:` cannot take an expression, every ref
+purpose, so `@workflows-v0` is expected to stay `@workflows-v0` after the package reaches 1.0 —
+bump it when a workflow breaks its callers, not when the package does. Because `uses:` cannot take an expression, every ref
 into this repo repeats the tag literally; `check-major-tag-refs.mjs` fails the build if `MAJOR_TAG`
 and those refs disagree, which is the mistake that would otherwise ship silently during a bump.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "apify-test-tools",
-  "version": "0.9.1-beta.8",
+  "version": "0.9.1-beta.9",
   "type": "module",
   "description": "TBD",
   "repository": {