feat(ci): add core CI workflow with build, test, and migration checks

[balazs-szucs]

🚀 Pull Request

📝 Description

Sample workflow: https://github.com/balazs-szucs/booklore/pull/72

This pull request introduces several new CI/CD workflows and enhancements to the BookLore project, focusing on improving build quality, code integrity, and asset validation. It adds comprehensive GitHub Actions workflows for building, testing, type checking, and scanning both frontend and backend code. Additionally, it implements asset integrity checks for backend test assets and improves type safety and error handling in frontend code. Some dependency and configuration updates are also included.

🛠️ Changes Implemented

CI/CD Workflow Enhancements:

• Added a comprehensive build and test workflow (core-build.yml) that runs frontend and backend tests, builds Docker images, and uploads artifacts for both architectures, ensuring code quality before merging.
• Introduced a type checking and compilation workflow (core-type-checking.yml) that runs TypeScript checks and compilation for the frontend and Java compilation for the backend, acting as a gatekeeper for type-safe code.
• Added a Java CI workflow (core-ci.yml) that performs backend build, unit/integration tests, asset validation, and security scanning using Trivy.
• Created a reusable shared setup workflow (util-shared-setup.yml) and a composite Java/Gradle setup action for DRY configuration across workflows

Backend Asset Validation and Build Improvements:

• Enabled Flyway database migration plugin in the backend build (build.gradle) for improved schema management.

Frontend Testing and Type Safety:

• Added a unit test for the main AppComponent to improve frontend test coverage.
• Improved type annotations and error handling in MetadataRestoreDialogComponent for better type safety.
• Updated BookService with new methods for backup and restore of book metadata, improving API coverage and maintainability.

Dependency and Configuration Updates:

• Updated frontend dependency zone.js to a compatible version to resolve build or runtime issues.

🧪 Testing Strategy

📸 Visual Changes (if applicable)

⚠️ Required Pre-Submission Checklist

• Code adheres to project style guidelines and conventions
• Branch synchronized with latest develop branch
• Automated unit/integration tests added/updated to cover changes
• All tests pass locally (./gradlew test for backend)
• Manual testing completed in local development environment
• Flyway migration versioning follows correct sequence (if database schema modified)
• Documentation pull request submitted to booklore-docs (required for features or enhancements that introduce user-facing or visual changes)

💬 Additional Context (optional)

[balazs-szucs]

@acx10,

I hope this format works well. I intend to submit the rest of the GHA workflows in today and tomorrow. My main aim is to make them each suite 'standalone' (meaning they can run alone) so that you can review and accept them on a one-by-one basis

By suite I mean the items described in the list here:
#1850 (comment)

E.g., setup job -> test jobs -> summary job, also as seen on the picture in PR message or below:

[balazs-szucs]

The changes that might seem unrelated were included to ensure the test compile. The frontend changes address fundamentally broken code; unfortunately, these fixes, along with the zone.js downgrade, were necessary just to make it compile in the first place.

[acx10]

This looks great overall.

How long does it take to run the full test suite?

[acx10]

Should this run first in the pipeline? If the Flyway check fails, it probably doesn’t make sense to continue with the rest of the steps.

[balazs-szucs]

My thought process is: less expensive going to more expensive (although GHA for OSS project is free). If there is actually seriously wrong with the code it fail at the first workflow, no matter what it is. But I can switch them around it's not that difficult at the end of the day 😄

[acx10]

I’m mostly thinking in terms of failing fast and as early as possible. If Flyway is broken, we can stop immediately and save time across the rest of the pipeline.

And yeah, GHA is free for OSS right now, but who knows, usage limits, throttling, or policy changes can always happen later. Optimizing for quick failure feels like a good long-term habit.

Happy to go either way, just sharing the rationale.

[balazs-szucs]

How long does it take to run the full test suite?

Ah as for the question not sure? I would wager like 6-7 minutes. But I push and update and clock it. But it'll depend also on cache, and lot of misc, stuff so there isn't 1 definitive answer to this.

[acx10]

Makes sense. I wasn’t after a precise timing, more whether it meaningfully increases the pipeline runtime, and if running it on every PR/build is practical.

[balazs-szucs]

(I think) the best approach would be to add a 'gatekeeper' GHA job that someone must trigger manually or via other deliberate means, such as making a specific comment (e.g., /run-ci jobs comment or something and have few authorized users.). And basically make everything dependent on that manual workflow finishing.

TLDR: Have a large test suite, but have responsible people take charge of it 😓

What do you think? Though, ChatOps and stuff like that is a real pain to configure but it seems to be the best option for me.

[acx10]

Agreed. The jobs included in this PR are fast enough to execute on every PR and PR push, providing immediate feedback.

For longer-running tests, such as integration, smoke, or regression, we should define a clear strategy regarding scheduling and authorized triggers, aligning with the concept of a manual or controlled 'gatekeeper' workflow for heavier suites (prospective).

[balazs-szucs]

Since workflows like manual triggers and ChatOps generally need to exist on the default branch to function correctly, testing them in isolation is difficult. My plan is to submit the GitHub Action now, including a setup workflow to make the future manual trigger easier to implement. Unfortunately, due to constraints, that is as far as I can go.

Regarding this specific workflow, I can push my commits but only trigger the workflow when I believe the code is truly finished. We can take a similar approach with other contributors: ask if their code is ready and make a judgment call on whether to run the full test suite. Since we don't 'need' to run this on every commit, we can use this 'light' suite to finalize the manual trigger implementation (when the manual workflow works with this, it would be trivial to implement for every other) and then decide later if this should remain behind a manual trigger or not.

Hope I am making sense 😄

[balazs-szucs]

This also coming along nicely, though not yet 100% done.

[acx10]

Since workflows like manual triggers and ChatOps generally need to exist on the default branch to function correctly, testing them in isolation is difficult. My plan is to submit the GitHub Action now, including a setup workflow to make the future manual trigger easier to implement. Unfortunately, due to constraints, that is as far as I can go.

Regarding this specific workflow, I can push my commits but only trigger the workflow when I believe the code is truly finished. We can take a similar approach with other contributors: ask if their code is ready and make a judgment call on whether to run the full test suite. Since we don't 'need' to run this on every commit, we can use this 'light' suite to finalize the manual trigger implementation (when the manual workflow works with this, it would be trivial to implement for every other) and then decide later if this should remain behind a manual trigger or not.

Hope I am making sense 😄

Makes sense, using the light suite to finalize the manual trigger is a smart approach, and once it’s working here, rolling it out to other workflows will be straightforward.

[acx10]

I just added check-for-migrations and flyway-migration-preview to develop, so we can probably remove those as yours is more comprehensive.

[balazs-szucs]

Ah, there is also usage tab apparently that tells the overall time:

[acx10]

Suggested change

	branches: ["develop", "main"]
	branches: ["develop", "master"]

[balazs-szucs]

Ah, true! Thanks! Will fix shortly.

[acx10]

The tagging workflow should be preserved from the existing pipeline.

[balazs-szucs]

To give a bit of context: I originally planned this as its own thing, which is why I kept the original existing pipeline intact. It was a deliberate choice, but I can certainly implement the original into this new one, it's just a slight change of plan. I agree that if we aren't keeping the original, this should be adjusted. I'll make the commits shortly

[acx10]

From my perspective, keeping the original pipeline would be redundant, as the new pipeline already covers most of its functionality in a more comprehensive way. Based on that, I was under the impression that the remaining pieces from the original pipeline would be adapted and incorporated into this new one. In that case, it would make sense to remove the old pipeline and move its remaining responsibilities, such as tagging and caching, into the new workflow.

[balazs-szucs]

Addressed in: f3adee0

Basically re-added the old workflow. Also renamed the main references to master.