feat(ci): add CI tests

[balazs-szucs]

No description provided.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[acx10]

@balazs-szucs Wow, that’s quite a bit going on. Do we actually need all of these pieces? We don’t even have this level of complexity at my company.

[balazs-szucs]

In the meantime, I opened this PR to mirror the final configuration state:

https://github.com/balazs-szucs/booklore/pull/42

@balazs-szucs Wow, that’s quite a bit going on. Do we actually need all of these pieces? We don’t even have this level of complexity at my company.

You are right, it is complex. Much of this workflow (though not all) was refined during my work with Stirling-PDF, and I wanted to bring those improvements here. I will add attributions to the files soon to credit the original contributors. Regarding licensing: my changes are substantial, and MIT is compatible with GPLv3.

Do we need it? Strictly speaking, no. However, since GitHub Actions usage is effectively unlimited for public open-source projects and the maintenance overhead is minimal, I believe the benefits outweigh the costs. If it catches even one bug, it’s worth having. I guess the only downside is the notification noise, but that can be turned off 😂

To be honest, I even planned to add more (mainly macOS testing), but life got in the way and I was getting frustrated with the testing 😂. This is a draft, though, I want you to feel comfortable with the changes. Please consider this a collaborative effort; I can (and will) adjust it to fit your vision if you have concrete feedback. But from my perspective, this is a solid baseline, and we will see where we go from here. E.g., target Java 25 for possible migration when they resolve stuff upstream, OS X builds, Tests with actual Books/PDFs (I didn't want to add binaries to this PR but a very much better way to test some stuff would be add them), etc...