Add PowerShell build scripts and document them in the README - #11
Conversation
Adds .ps1 equivalents of the existing .sh build scripts for Windows users, and updates README.md to reference them alongside the bash scripts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Custom build scripts should be avoided, in my experience. Especially several scripts that bypass the normal build process. Such custom scripts remove the standardization from the build process and makes debugging difficult. |
What do you suggest ? |
|
eventually the functionality for generating the resources should be taken by the main tooling. For example, if this means sushi pre-processing, a discussion in zulip for that. and keeping divergence at minimum, even if this means it is less convenient for authors (as long as it is not too burdensome). Avoid the custom scripts to become the new "standard" |
|
It would be great if multi-version would be directly supported by sushi ; but for the time being -since we have an immediate need- I dont see too many alternatives. ...topic for the EU FHIR IG Management Group :-) |
The Linux jobs never run the PowerShell scripts, so they would drift away from their bash counterparts unnoticed. A Windows job renders the R4 templates with _preprocessMultiVersion.ps1 and compiles the result with SUSHI, which catches a broken script, a botched copy or mangled encoding. It skips the publisher build, as that is slow and Windows runner minutes are billed at a higher rate, and deployment does not depend on it, as these scripts have no influence on what is published. Drop _commitToMainRepos.ps1. Publishing is what the deployment workflow does on every push, and the bash original is being removed for that reason, so a per-platform second implementation of it is not worth maintaining. Render the templates one after another in _preprocessMultiVersion.ps1. Start-Job is not the equivalent of a forked subshell, it starts a whole PowerShell process per file, and with thirty templates that is thirty runspaces, each starting npx on top. Silence the progress bar around the publisher download in _updateBuildTools.ps1. Invoke-WebRequest redraws it for every chunk it receives, which on a 200 MB download costs far more than the transfer itself.
The first run showed where its time goes: of the three and a half minutes the SUSHI step took, three and a half minutes went into downloading packages and six seconds into the actual compile. hl7.terminology.r4 alone took 69 seconds, xver-r5.r4 another 73. None of that says anything about the scripts under test, and Windows runner minutes are billed at a higher rate. The key follows the dependency list in sushi-config.liquid.yaml. A stale cache is still restored, as SUSHI then only fetches the packages that changed.
This is a public repository, where GitHub-hosted runners are free and the higher rate for Windows minutes does not apply. What remains is wall clock: the job is the slowest of the three, and the content it builds is already validated twice by the Linux jobs, so it only has to show that the scripts themselves work.
Same change as on the bash side: npx re-resolves liquidjs on every call, which on Windows costs roughly two seconds per template against a tenth of a second for the render itself. liquidjs is installed once into .liquidjs and run through node directly. bin/liquid.js is called rather than the wrapper in node_modules/.bin. The wrapper is an extensionless shell script Windows cannot execute and would need its own .cmd variant, whereas the .js entry point behaves the same on every platform. The Windows job measured the old behaviour at 58 seconds for thirty templates, so the next run on this branch shows what it is worth.
Cover the PowerShell scripts with a Windows job and drop the deploy port
…ell-scripts # Conflicts: # .gitignore # README.md
|
@gcangioli i update this PR with minor fixes, and a windows runner checking the windows scripts |
3 participants
Summary
.ps1equivalents of the existing.shbuild scripts for Windows users (_preProcessAndCheckAll.ps1,_preprocessMultiVersion.ps1,_updateBuildTools.ps1,_commitToMainRepos.ps1)README.mdto reference the PowerShell scripts alongside the bash scripts (Prerequisites, Quick start, Scripts table, Building the IGs, Updating build tooling, Publishing)Test plan
.ps1scripts on Windows to confirm parity with the.shversions