Make the build process run automatically with each release. This will likely be using Github actions.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Sebastian_Berlin-WMSE | T321011 ☂️ WMSE development support of the Pattypan tool | |||
Resolved | Sebastian_Berlin-WMSE | T323103 Create Windows executable | |||
Declined | None | T323121 Automate build process |
Event Timeline
I've experimented a bit with Github actions on https://github.com/sebastian-berlin-wmse/pattypan/actions. So far I've managed to build Pattypan and prepared a bit for creating an executable with 7-zip.
After a bit of testing it seems that actions/setup-java with Java 17, jre+fx from Azul is the way to go. Adoptium appears to be a slightly more recommended (according to https://whichjdk.com and it's at the top of the list in the documentation of actions/setup-java), but it's distribution didn't work with jre+fx.
Got an Github action workflow working that saves an EXE: https://github.com/sebastian-berlin-wmse/pattypan/actions/runs/3733366624.
Pattypan starts and seems to work, though there have been crashes. Not sure if this is due to the (quite unstable) VM setup I have for Windows, the Java distribution or something else. This also happens when I unpack the files from the EXE and run, so I don't think that 7-zip is what causes it.
The error is:
# # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000261d413101e, pid=3876, tid=4848 # # JRE version: OpenJDK Runtime Environment Zulu17.38+21-CA (17.0.5+8) (build 17.0.5+8-LTS) # Java VM: OpenJDK 64-Bit Server VM Zulu17.38+21-CA (17.0.5+8-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # J 4095 c1 com.sun.prism.impl.ps.BaseShaderGraphics.initLCDSampleRT()V javafx.graphics@17.0.5 (231 bytes) @ 0x00000261d413101e [0x00000261d4130540+0x0000000000000ade] # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Users\IEUser\Desktop\pattypan-exe\hs_err_pid3876.log Compiled method (c1) 18475 4095 3 com.sun.prism.impl.ps.BaseShaderGraphics::initLCDSampleRT (231 bytes) total in heap [0x00000261d4130210,0x00000261d41325f0] = 9184 relocation [0x00000261d4130368,0x00000261d4130510] = 424 constants [0x00000261d4130520,0x00000261d4130540] = 32 main code [0x00000261d4130540,0x00000261d4131da0] = 6240 stub code [0x00000261d4131da0,0x00000261d4131e78] = 216 oops [0x00000261d4131e78,0x00000261d4131e80] = 8 metadata [0x00000261d4131e80,0x00000261d4131f60] = 224 scopes data [0x00000261d4131f60,0x00000261d4132278] = 792 scopes pcs [0x00000261d4132278,0x00000261d4132538] = 704 dependencies [0x00000261d4132538,0x00000261d4132580] = 72 nul chk table [0x00000261d4132580,0x00000261d41325f0] = 112 Compiled method (n/a) 18616 2513 n 0 com.sun.prism.d3d.D3DShader::enable (native) total in heap [0x00000261daeba190,0x00000261daeba560] = 976 relocation [0x00000261daeba2e8,0x00000261daeba318] = 48 main code [0x00000261daeba320,0x00000261daeba558] = 568 oops [0x00000261daeba558,0x00000261daeba560] = 8 # # If you would like to submit a bug report, please visit: # http://www.azul.com/support/ #
and the log is here:
I tried changing the compression level when creating the archive, but that didn't make much difference. The size went from 58.5 MB (level 1) to 44.3 MB (level 9), which is about 25% decrease, but only 14.2 MB. Launch time (from saying "yes" in the unknown app popup to seeing the Pattypan UI) was pretty much the same, about 16 sec.
@Lokal_Profil ran the EXE on a "real" Windows installation and it worked. There were no crashes like on the VM. There was a couple of extra security popups due to the EXE not being signed.
Added an action that creates a release with the EXE in assets, see e.g. https://github.com/sebastian-berlin-wmse/pattypan/releases/tag/release-test. This should be able to automatically run the workflow when a tag is created (and its name matches a pattern for release).
@Lokal_Profil, if you have no objections I think this can be closed as "declined". It's unlikely that this will be implemented anytime soon in the upstream repo and given the slow release rate of Pattypan, doing this manually should be fine.