Files
dc/.gitea/scripts/tests/cypress-changes.test.sh
T
dc 2e5b02aa51
Build / Build-and-ng-test (pull_request) Successful in 4m26s
Build / lighthouse (pull_request) Failing after 2m12s
Build / Build-and-test-development (pull_request) Canceled after 12m37s
ci(build): run the Lighthouse audit in the build workflow
The audit needs the production build, and an artifact belongs to the run that
produced it (needs: cannot cross workflows), so as a separate workflow it
compiled the frontend a second time - 92-104s measured - and then started an
ng serve that nothing audited: every URL in client/lighthouserc.js is on
:5000, which the SASjs server feeds from client/dist.

As a job in build.yaml it takes the change decision from the build job
(the same inputs gate both), downloads client-dist, and patches appLoc in the
built index.html instead of compiling a patched copy of the source. The
second compile, the dev server and the source generator in this job are gone;
what remains is node_modules for lhci, the pinned CLI, the SASjs server and
the mock estate deploy.

The check name moves from 'Lighthouse Checks / lighthouse' to
'Build / lighthouse'; there are no required contexts to update. The
changed-path matcher already covers everything this job reads, so its only
change is a comment and the fixture that used to assert lighthouse.yaml was
not an input.
2026-11-07 10:46:11 +00:00

61 lines
2.3 KiB
Bash

#!/usr/bin/env bash
# The path list in cypress-changes.sh is the whole gate: drop an alternative
# and the Cypress suite silently stops running for a class of change, with a
# green job that just finished sooner. These cases pin the list to what the
# suite actually reads, and run in the build job on every pull request.
#
# Run by hand: bash .gitea/scripts/tests/cypress-changes.test.sh
set -uo pipefail
here="$(cd "$(dirname "$0")" && pwd)"
matcher="$here/../cypress-changes.sh"
fails=0
check() { # <expected> <path>...
local want="$1" got
shift
got=$(printf '%s\n' "$@" | bash "$matcher" --match)
if [ "$got" != "$want" ]; then
echo "FAIL: expected $want for: $*"
echo " got: $got"
fails=$((fails + 1))
fi
}
# Everything the Cypress job reads: the client it drives, the mock estate it
# deploys, the CLI pin it installs, the scripts that decide what it runs, and
# the dependency/workflow files that change the first two.
check true client/src/app/app.component.ts
check true sas/mocks/sasjs/services/admin/makedata.js
check true sas/mocks/sasjs/services/admin/createdemodata.js
check true sas/package.json
check true .gitea/scripts/cypress-specs.sh
check true package-lock.json
check true .gitea/workflows/build.yaml
# Not inputs: a sas/ service the mock estate does not deploy, documentation,
# another workflow (only build.yaml decides what these jobs run), an unrelated
# directory whose name starts with "client", and the sas lockfile (the job
# installs the CLI by version string, so the lockfile cannot change what it
# resolves).
check false sas/macros/mp_abort.sas
check false AGENTS.md
check false docs/readme.md
check false .gitea/workflows/release.yaml
check false clientx/foo.ts
check false sas/package-lock.json
# The mock tree's own tests are not deployed, so a pull request that changes
# only them cannot change what the browser is served. A change that touches
# them next to a service still counts.
check false sas/mocks/test/sas9-separators.test.js
check false sas/mocks/test/sasjs-webout.test.js
check true sas/mocks/test/sas9-separators.test.js sas/mocks/sasjs/services/x.js
check true sas/mocks/sas9/sasjs/services/editors/getdata.js
if [ "$fails" -ne 0 ]; then
echo "cypress-changes matcher: $fails case(s) failed"
exit 1
fi
echo "cypress-changes matcher: all cases passed"