local-liferay-api-test

star 0

Test headless-delivery-ext REST APIs against a locally running Liferay with support/sarenat authentication, Playwright API verification, deployment, and log diagnosis. Default to the workspace-local `bundles/` runtime for builds, deploys, examples, and verification. Only target `/opt/liferay` when the user explicitly asks for the live portal. Do not run integration tests unless explicitly requested.

wsyski By wsyski schedule Updated 6/1/2026
play_arrow Run Skill in Manus View GitHub

name: local-liferay-api-test description: Test headless-delivery-ext REST APIs against a locally running Liferay with support/sarenat authentication, Playwright API verification, deployment, and log diagnosis. Default to the workspace-local bundles/ runtime for builds, deploys, examples, and verification. Only target /opt/liferay when the user explicitly asks for the live portal. Do not run integration tests unless explicitly requested. disable-model-invocation: true

Defaults

  • Base URL: http://localhost:6080/o/headless-delivery-ext/v1.0
  • OpenAPI URL: http://localhost:6080/o/headless-delivery-ext/v1.0/openapi.json
  • Auth: support / sarenat
  • Liferay login: user support, password sarenat
  • Default runtime for repo work: workspace-local bundles/
  • Use -Pliferay.workspace.home.dir=bundles explicitly for integration tests and any server-backed workspace command.
  • Do not deploy to or mutate /opt/liferay unless the user explicitly asks for the live portal.
  • Do not use test@liferay.com:test for this local portal; it may return 403.
  • Use support:sarenat for live local API checks because this portal's effective permissions/auth differ from the workspace test runtime.
  • Do not run testIntegration unless the user explicitly asks.
  • If the user does ask for workspace integration tests, run them against the workspace runtime with -Pliferay.workspace.home.dir=bundles.
  • If the user is testing against the live site on /opt/liferay, do not run blade gw testIntegration in that workflow. Live-site checks and workspace integration tests are mutually exclusive.

Runtime Safety

  • Treat workspace bundles/ as source of truth for examples, deploy verification, and integration tests.
  • Before any deploy or test command, check the effective target runtime path.
  • Never assume /opt/liferay is safe just because it exists; it may be a live or shared portal.
  • If user asks to check a live portal on localhost:6080, read and test it directly, but keep build/deploy/test side effects inside workspace bundles/ unless user explicitly requests live deploy work.
  • If you must target /opt/liferay, state that explicitly in your plan/update before running commands.

Parameters

  • Accept structure descriptions and template descriptions as comma-delimited parameter lists when the user wants the same GET/PUT check repeated for multiple resources.
  • Trim spaces around each description before calling the API.
  • For clone checks, append a user-requested suffix such as -new to each source description unless the user provides explicit target descriptions.
  • If the target description such as *-new already exists, treat the PUT as an overwrite test and compare the final saved resource with the source.

Example parameter value:

structureDescriptions=text-hint-test-simple, separator-test, multi-selection-test
templateDescriptions=basic-template, marketing-template

Fast API Check

Use direct HTTP for quick reproduction, then use playwright-helper when the user requests Playwright/browser validation.

curl -i -u support:sarenat \
  -H 'Accept: application/json' \
  'http://localhost:6080/o/headless-delivery-ext/v1.0/sites/{siteId}/content-structures/by-description/{description}'

For PUT, save the source response and send it back as JSON:

curl -s -u support:sarenat \
  -H 'Accept: application/json' \
  'http://localhost:6080/o/headless-delivery-ext/v1.0/sites/{siteId}/content-structures/by-description/{sourceDescription}' \
  -o /tmp/opencode/source-structure.json

curl -i -u support:sarenat \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -X PUT \
  --data-binary '@/tmp/opencode/source-structure.json' \
  'http://localhost:6080/o/headless-delivery-ext/v1.0/sites/{siteId}/content-structures/by-description/{targetDescription}'

Expected successful structure clone response:

  • HTTP 200
  • description.<locale> equals {targetDescription}
  • If cloning to a new description, dataDefinitionKey should be based on the target description, not the source body key.
  • If the target already exists, verify the existing resource was overwritten with the source content rather than skipped.
  • Compare the cloned structure with the original and call out any differences beyond expected path-driven changes such as description and dataDefinitionKey.

Site ID Gotcha

Always verify the site ID before diagnosing endpoint behavior.

  • Access logs may reveal the actual successful site ID.
  • In this local environment, confusing 3103 with 32103 caused false 404 results.
  • If a source GET returns 404, check access logs and the response siteId from a known-good GET before changing code.

Playwright Verification

Use playwright-helper for local API verification when requested.

Prompt pattern:

Use Playwright to verify the live API flow against http://localhost:6080 using Basic auth support:sarenat. Accept comma-delimited lists of structure descriptions and template descriptions, GET each by-description resource, then PUT each response body to a new by-description value using the requested suffix. If the target already exists, verify it is overwritten. Report exact statuses and key response fields: description and dataDefinitionKey or templateKey. Compare each saved resource with its source and call out any non-path-driven differences. Do not modify files.

Deploy Local Module

Compile before deploy when code changes:

blade gw compileJava -p modules/headless-delivery-ext/headless-delivery-ext-impl

Deploy to the workspace-local running bundle by default:

blade gw deploy -p modules/headless-delivery-ext

For safe workspace deploys, prefer:

blade gw deploy -p modules/headless-delivery-ext -Pliferay.workspace.home.dir=bundles

Only deploy to /opt/liferay when the user explicitly requests live-portal deployment.

If the user specifically asks for gradle clean build deploy, run the requested Gradle command. Otherwise prefer blade gw per workspace rules.

Logs

Check these workspace paths first:

  • bundles/logs/liferay.<date>.log
  • bundles/logs/companies/*/liferay-*.log
  • bundles/tomcat/logs/catalina.out

Only check /opt/liferay logs when user explicitly asked to work against the live portal:

  • /opt/liferay/logs/liferay.<date>.log
  • /opt/liferay/logs/companies/*/liferay-*.log
  • /opt/liferay/tomcat-9.0.90/logs/access-*.log

Useful symptoms:

  • Body description must contain path description: stale deployment or old path/body validation code.
  • StructureDuplicateStructureKeyException: create-as-new reused source dataDefinitionKey.
  • HTTP 404 on GET: likely wrong site ID or missing resource.
  • HTTP 404 on typo path like content-structurets: route does not exist.

Do Not

  • Do not run integration tests unless explicitly requested.
  • Do not deploy to /opt/liferay unless explicitly requested.
  • Do not clear OSGi state for the live /opt/liferay portal unless explicitly requested.
  • Do not assume generated files should be committed.
Install via CLI
npx skills add https://github.com/wsyski/blade-workspace --skill local-liferay-api-test
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator
wsyski
wsyski Explore all skills →