ci(journeys): start the journeys jobs after the site job again

.github/workflows/ci.yml

@@ -604,10 +604,9 @@ jobs:
   # all: Chromium's journeys in three shards of about the same time
   # (harness/shards.ts, from durations.json), desktop Firefox's and
   # WebKit's together, and the phone's, the slowest of the others, in a
-  # job of its own. Each job pays the setup again (about a minute), for
-  # a shorter wall time; it sets up while the site job builds, starting
-  # the server in the background, and waits for the build only before
-  # the journeys run. When one
+  # job of its own. Each job, started once the site job is done, pays
+  # the setup again (about a minute), for a shorter wall time; it starts
+  # the server in the background while the browsers are set up. When one
   # fails, the others are canceled (fail-fast), as their result no longer
   # changes the run's and they take long; the job's summary names the
   # step it failed in, and its
@@ -622,15 +621,11 @@ jobs:
   # retried (retries: 0, playwright.config.ts).
   journeys:
     name: journeys (${{ matrix.name }})
-    needs: gate
+    needs: [gate, site]
     if: needs.gate.outputs.jobs == 'all'
     runs-on: ubuntu-latest
-    # The site job's 30 minutes, and the journeys' own.
-    timeout-minutes: 45
-    permissions:
-      contents: read
-      # To see when the site job is done.
-      actions: read
+    # The journeys' own time: the job starts once the site job is done.
+    timeout-minutes: 25
     strategy:
       fail-fast: true
       # name: the job's, and its blob's (journeys-report lists them);
@@ -684,8 +679,8 @@ jobs:
           name: journeys
           key: ${{ hashFiles('e2e/journeys/css/compose.yml') }}
       - run: npm run css:prepare -w @solid-memo/e2e-journeys
-      # The server, up while the browsers are set up and the site is
-      # built; "Wait for the Solid server" below fails if it never is.
+      # The server, up while the browsers are set up; "Wait for the
+      # Solid server" below fails if it never is.
       - name: Start the Solid server
         run: |
           nohup node e2e/journeys/harness/cssServer.ts > "$RUNNER_TEMP/css.out" 2>&1 &
@@ -741,30 +736,6 @@ jobs:
             exit 1
           fi
           echo "journeys=$journeys" >> "$GITHUB_OUTPUT"
-      # The site job's build, once that job is done: the latest try of
-      # it in this run, so a run started again waits for its new build,
-      # and a journeys job alone run again takes the one there is. It
-      # waits as long as the site job may take (its timeout), and a look
-      # at the jobs that fails is tried again at the next.
-      - name: Wait for the site's build
-        env:
-          GH_TOKEN: ${{ github.token }}
-          GH_REPO: ${{ github.repository }}
-          RUN_ID: ${{ github.run_id }}
-        run: |
-          site=unknown
-          for _ in $(seq 1 180); do
-            site=$(gh api "repos/$GH_REPO/actions/runs/$RUN_ID/jobs?filter=latest&per_page=100" \
-              --jq '[.jobs[] | select(.name == "site")][0] | "\(.status) \(.conclusion)"') ||
-              site=unknown
-            case $site in
-              "completed success") exit 0 ;;
-              completed*) echo "::error::The site job ended without its build ($site)."; exit 1 ;;
-            esac
-            sleep 10
-          done
-          echo "::error::The site job was not done within 30 minutes ($site)."
-          exit 1
       - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
         with:
           name: site

docs/testing.md

@@ -397,9 +397,9 @@ in (`app.step(title, body, { in: ["chromium"] })`), and the report
 shows it skipped elsewhere, as for the reload journey's statistics and
 the shared link's import.
 
-CI runs them in five jobs side by side, each paying about a minute of
-setup while the `site` job builds: it starts the Solid server in the
-background and waits for the build only before the journeys run.
+CI runs them in five jobs side by side once the `site` job is done,
+each paying about a minute of setup: it starts the Solid server in the
+background while the browsers are set up.
 Chromium's run in three shards of about the same time,
 `journeys (chromium-1)` to `journeys (chromium-3)`.
 [shards.ts](../e2e/journeys/harness/shards.ts) puts the longest
@@ -675,7 +675,7 @@ jobs run side by side, each
 | `solid-memo-client (unit)` | deterministic | advisory: with `SOLID_CLIENT=solid-memo-client`, `solid`'s unit tests without those of the four Inrupt modules the client replaces (`src/client/{access,rdf,resources,session,session.library}.test.ts`), `solid`'s round trip, and the unit tests of `shacl`, `composition` and `web`, each step run even when one before it failed. `web`'s build test builds the site without the docs' diagrams (`DOCS_DIAGRAMS=skip`), so the job installs no Chromium; `check` draws them. npm runs them, not Turbo, so no result comes from a cache, and without coverage. The client's own tests are `check`'s ([solid-memo-client.md](solid-memo-client.md#tests)) |
 | `solid-memo-client (<server>)` | timing-dependent | advisory: the end-to-end tests with `SOLID_CLIENT=solid-memo-client`, one job per blocking server, on the images in `pod`'s cache, which it restores and only `pod` saves. What the server printed is kept when the job fails. Neither of the `solid-memo-client` jobs fails the run or `ci-ok` when it fails (`continue-on-error`), so neither holds back a merge, a release or a deploy |
 | `journeys (<name>)` | timing-dependent | the user journeys, on `site`'s build: all in Chromium in three shards of about the same time, those that differ between engines in desktop Firefox and WebKit, in one job, and on a phone, in another (Browsers, above) |
-| `journeys-report` | deterministic | nothing: on `main`, after the `journeys` jobs, even when one failed (then with what the canceled ones ran), it merges their runs, or those of the run that tested its code (the gate's `tested-by`), into the `journeys-report` artifact the deploy publishes ([User journeys](#user-journeys)). It fails without every job's report when the journeys passed or the gate skipped them, not when they failed, as they do when the `site` job ends without its build. Its failure fails the run, holding back the release and the deploy, but not `ci-ok` |
+| `journeys-report` | deterministic | nothing: on `main`, after the `journeys` jobs, even when one failed (then with what the canceled ones ran), it merges their runs, or those of the run that tested its code (the gate's `tested-by`), into the `journeys-report` artifact the deploy publishes ([User journeys](#user-journeys)). It fails without every job's report when the journeys passed or the gate skipped them, not when the `site` job's failure skipped them. Its failure fails the run, holding back the release and the deploy, but not `ci-ok` |
 | `docs` | deterministic | the docs' links, every file's license, and `publiccode.yml` ([Documentation](#documentation)) |
 | `workflows` | deterministic | the workflows and local actions, by actionlint and zizmor (`npm run lint:workflows`, [The workflows](#the-workflows)) |
 | `commits` | deterministic | on a pull request only: each commit it adds follows Conventional Commits, by commitlint ([CONTRIBUTING.md](../CONTRIBUTING.md#commit-messages)), and its body or a commit closes its issue, or the body says it's one step of it (`npm run check:closes`; not for Renovate's) |