dc
133092502c
Two defects on the deploy screens, found on staging. 1. The folder picker's outer row reused Clarity's 'clr-input-wrapper' class, whose 'max-height: var(--clr-forms-input-wrapper-height)' clamps the row to the input's height. The row is flex-wrap: wrap, so once the Browse/Validate buttons wrapped (or the row was simply taller than one input) they overflowed the clamp, and the folder browser panel - positioned after the collapsed box - rendered on top of the input, the buttons and the surrounding text. Measured on staging: panel top 256 against input 248-272 and buttons 280-304; with the class dropped the row contains all its children and the panel starts at 312. 2. The Viya screen asked for the DC directory before the compute context, but the folder listing and the write check run inside the chosen context, as its batch identity - so the probes could inspect a file system the deployment itself would not use. The fields are reordered (admin group, then batch id / compute context, then DC Loc last) and the picker now runs DIRLIST and WRITECHECK with the selected context in the adapter request config, which every Viya executor path honours. The SAS 9 / SASjs screens pass no context and behave exactly as before. Tests: a Cypress spec drives the real deploy screen estate - the picker row must contain its own children and the panel must start below them; both tests fail with the clamp reintroduced. A rendered TestBed spec pins the Viya field order (admin group < compute context < DC Loc) and fails with the old order. Unit specs pin the probe config: no context on SAS 9 / SASjs, the chosen context on Viya.
60 lines
3.0 KiB
Bash
Executable File
60 lines
3.0 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# The Cypress specs CI runs, and the order they run in.
|
|
#
|
|
# ORDER MATTERS. These specs share one mock estate that is seeded once per job,
|
|
# so several of them depend on the state they find:
|
|
#
|
|
# - csv-limited asserts the free-tier "Locked Feature" modal, which an earlier
|
|
# spec can remove by planting a valid licence. It has always run first.
|
|
# - hook-programs asserts that an edit raises an approval row against its
|
|
# target table; it runs early, before other specs have added rows to the
|
|
# approval tables.
|
|
# - metanav only reads the metadata tree, and applies a licence key so it can
|
|
# run on its own; it goes last so that key cannot change another spec.
|
|
# - va-ddc-host asserts nothing about licensing, so it works on either side of
|
|
# metanav; it sits before it, which leaves metanav last.
|
|
#
|
|
# Specs added later are appended rather than inserted, so the sequence that was
|
|
# known green keeps its shape. metanav is the exception - it has to stay last for
|
|
# the key it plants, so a new spec goes in front of it.
|
|
#
|
|
# download was held out while its selectors were stale - see
|
|
# https://git.datacontroller.io/dc/dc/issues/398. Its first case uploads a fixture
|
|
# to mpe_x_test and submits it, so it creates the approval it downloads instead of
|
|
# depending on what earlier specs leave behind. That approval stays: the CI job
|
|
# deletes the appLoc and re-runs makedata before the specs, so nothing accumulates
|
|
# between runs, but a hand-run against a reused estate leaves one pending row per
|
|
# run. It is appended because a spec added later goes on the end rather than
|
|
# reordering the sequence that was known green.
|
|
set -euo pipefail
|
|
|
|
SPECS="csv-limited hook-programs liveness editor excel-multi-load excel csv filtering filter-panel licensing viewer-labels full-table-search viewbox stage browser-info ddl-export row-cell-limits derived-variables startupservice-launcher coltype-delete-record submitted-details embed-va deploy-folder-picker download va-ddc-host metanav"
|
|
|
|
# Specs that exist but are held out of CI, each with the reason. Listed here so
|
|
# the coverage check below can tell a deliberate exclusion from a forgotten file.
|
|
# Nothing is held out at present.
|
|
EXCLUDED=""
|
|
|
|
case "${1:-}" in
|
|
all)
|
|
# comma separated, the form `cypress run --spec` takes
|
|
for name in $SPECS; do printf 'cypress/e2e/%s.cy.ts,' "$name"; done | sed 's/,$//'
|
|
;;
|
|
coverage)
|
|
on_disk=$(cd "$2/client" && ls cypress/e2e/*.cy.ts | xargs -n1 basename | sed 's/\.cy\.ts$//' | sort)
|
|
listed=$(printf '%s\n' $SPECS $EXCLUDED | sort)
|
|
missing=$(comm -23 <(echo "$on_disk") <(echo "$listed"))
|
|
if [ -n "$missing" ]; then
|
|
echo "Specs that are neither run nor explicitly excluded:"
|
|
echo "$missing"
|
|
echo "Add them to SPECS (or EXCLUDED, with a reason) in .gitea/scripts/cypress-specs.sh"
|
|
exit 1
|
|
fi
|
|
echo "All $(echo "$on_disk" | wc -l) specs are accounted for: $(echo $SPECS | wc -w) run, $(echo $EXCLUDED | wc -w) excluded."
|
|
;;
|
|
*)
|
|
echo "usage: $0 {all|coverage <repo-root>}" >&2
|
|
exit 2
|
|
;;
|
|
esac
|