MaximBelov opened a new pull request, #314:
URL: https://github.com/apache/cordova-paramedic/pull/314

   Two independent fixes, both hit while trying to run a plugin's own `tests/` 
suite through paramedic on a current macOS. Either one alone leaves the run 
unable to finish, and neither shows up in CI here, which is why they have gone 
unnoticed.
   
   Happy to split into two PRs if you'd prefer them reviewed separately.
   
   ## 1. `--plugin` cannot pass plugin variables
   
   `installSinglePlugin` separates the plugin path from any trailing `--` 
arguments, then concatenates them back into a single string and passes that as 
one argv entry:
   
   ```js
   plugin = path.resolve(this.storedCWD, pluginPath) + args;
   ...
   ['plugin', 'add', plugin, ...utilities.PARAMEDIC_COMMON_ARGS]
   ```
   
   So the CLI reads the whole thing as one plugin spec:
   
   ```
   npm error path /abs/path/plugin --variable APP_ID=123/package.json
   npm error enoent Could not read package.json
   Error: [paramedic] Command failed: "cordova plugin add /abs/path/plugin 
--variable APP_ID=123 ..."
   ```
   
   That makes the documented `--plugin "./my-plugin --variable KEY=value"` form 
unusable for any plugin whose `<preference>` elements have no `default` — 
installation cannot succeed at all, since `cordova plugin add` requires those 
variables.
   
   Splitting the arguments and spreading them into the argv list fixes it. 
Plugins without variables are unaffected: with no ` --` in the string the 
argument list is empty and the spawn is byte-identical to before.
   
   One limitation, called out in the commit: arguments are split on whitespace, 
so a value containing a space still cannot be passed. That is the same shape as 
the existing ` --` heuristic in the function; doing it properly needs 
shell-style tokenisation and looked out of scope for a fix.
   
   ## 2. Simulator lookup compares runtime versions written to different depths
   
   `filterForSimulatorIds` requires `simIdMatch[2] === simulatorData.version`, 
but the two sides come from different tools. `cordova run ios --list 
--emulator` reports the minor version:
   
   ```
        iPhone-16-Pro, 18.3
   ```
   
   while `xcrun xctrace list devices`, which the simulator ids are read from, 
reports the patch version:
   
   ```
   iPhone 16 Pro (18.3.1) (A14B1090-294D-4E0B-9474-0C3F8B97394C)
   ```
   
   `'18.3' === '18.3.1'` is false, so no id is found, `getSimulatorData` logs 
`No simulator found.`, `simId` is left undefined and the run sits in `Waiting 
for test results...` until it times out.
   
   It only works when the installed runtime happens to have no patch component. 
On this machine 18.2 matched and 18.3.1 and 26.3.1 did not, which is the 
asymmetry that keeps it out of CI: the runner images ship runtimes whose 
versions are two components, a developer's Xcode usually does not.
   
   Now compared on dot boundaries, so the shorter version acts as a prefix of 
the longer without `18.3` also matching `18.30`.
   
   ## Verification
   
   Against a real third-party plugin with three mandatory variables (`APP_ID`, 
`APP_NAME`, `CLIENT_TOKEN`) and a 23-spec suite in its `tests/` directory, 
`cordova plugin add` via `--plugin "./plugin --variable ..."`, cordova-ios 
8.1.1, `--ci --cleanUpAfterRun`:
   
   | | before | after |
   | --- | --- | --- |
   | iPhone 16 Pro, iOS **18.2** (runtime version has no patch part) | plugin 
install fails, `ENOENT ... --variable APP_ID=.../package.json` | `Executed 23 
of 23 specs SUCCESS`, exit 0 |
   | iPhone 17 Pro, iOS **26.3.1** | `No simulator found.` then hangs in 
`Waiting for test results...` | `Executed 23 of 23 specs SUCCESS`, exit 0 |
   
   Exit codes propagate correctly either way: an intentionally failing spec 
still gives `Finished with exit code 1`.
   
   `eslint .` is clean.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to