After #30 (CI now installs OpenRegister development, so the openbuilt register + seed are created — see #29), the Newman job in CI is still red, now for collection-level bugs rather than a setup problem. From the CI run's Newman log:
tests/integration/openbuilt.postman_collection.json (and likely openbuilt-rbac / openbuilt-versioning / openbuilt-schema-editor) — several requests fire with an unsubstituted {{app_uuid}} / {{created_uuid}} (or an empty {uuid} path segment), e.g. PUT .../objects/openbuilt/application/{{app_uuid}} [404], PUT .../objects/openbuilt/application/ [404], GET .../objects/openbuilt/application//audit-trails [404]. The "GET hello-world / GET the created app" step that should pm.collectionVariables.set(...) the uuid isn't firing, or the variable names don't match between the extracting step and the consuming step. Fix the variable extraction (use data['@self'].id or data.results[0]['@self'].id consistently; the OR objects API wraps lists in {results:[...]}) and align the variable names.tests/integration/openbuilt-export-to-real-app.postman_collection.json — uses the schema slug exportJob (GET .../objects/openbuilt/exportJob/ [404]); the actual slug is export-job (per lib/Settings/openbuilt_register.json — exportJob is the schema name, export-job the slug). Also "Submit export — ZIP target returns 202 with UUID" doesn't get a 202 — investigate whether POST /api/applications/{slug}/exports needs a published app (resolve a slug with a built-app-route) or whether the export feature returns a different status; adjust the assertion / preconditions.- General: the reusable workflow runs every
*.postman_collection.json under tests/integration/; each chain collection was authored against the older base — re-validate each against current development + OR development.
Until this is fixed, the Newman CI job stays red (the rest of CI — PHPUnit ×6, all static analysis — is green).
After #30 (CI now installs OpenRegister
development, so theopenbuiltregister + seed are created — see #29), the Newman job in CI is still red, now for collection-level bugs rather than a setup problem. From the CI run's Newman log:tests/integration/openbuilt.postman_collection.json(and likelyopenbuilt-rbac/openbuilt-versioning/openbuilt-schema-editor) — several requests fire with an unsubstituted{{app_uuid}}/{{created_uuid}}(or an empty{uuid}path segment), e.g.PUT .../objects/openbuilt/application/{{app_uuid}} [404],PUT .../objects/openbuilt/application/ [404],GET .../objects/openbuilt/application//audit-trails [404]. The "GET hello-world / GET the created app" step that shouldpm.collectionVariables.set(...)the uuid isn't firing, or the variable names don't match between the extracting step and the consuming step. Fix the variable extraction (usedata['@self'].idordata.results[0]['@self'].idconsistently; the OR objects API wraps lists in{results:[...]}) and align the variable names.tests/integration/openbuilt-export-to-real-app.postman_collection.json— uses the schema slugexportJob(GET .../objects/openbuilt/exportJob/ [404]); the actual slug isexport-job(perlib/Settings/openbuilt_register.json—exportJobis the schema name,export-jobthe slug). Also "Submit export — ZIP target returns 202 with UUID" doesn't get a 202 — investigate whetherPOST /api/applications/{slug}/exportsneeds a published app (resolve a slug with abuilt-app-route) or whether the export feature returns a different status; adjust the assertion / preconditions.*.postman_collection.jsonundertests/integration/; each chain collection was authored against the older base — re-validate each against currentdevelopment+ ORdevelopment.Until this is fixed, the Newman CI job stays red (the rest of CI — PHPUnit ×6, all static analysis — is green).