Fluxzero 1.48.0
1.48.0 (2025-11-18)
Changes
Feature/build improvements (#58) (
f7534b9)* fix: always use ./mvnw instead of mvn so we consistently use the same maven version
* ci: refactor deployment pipeline for parallel execution
Restructure the deployment workflow to run jobs in parallel after a
successful build, reducing total pipeline time from ~10-15 minutes to
~5-7 minutes (50% improvement).Key changes:
1. Split deploy.yml into 6 independent jobs:
- build-and-test: Critical path that must succeed first, builds JARs
once and uploads as artifacts
- maven-central: Deploys to Maven Central (parallel after build)
- javadoc: Generates and publishes documentation (parallel)
- github-release: Creates GitHub release (parallel)
- docker-test-server: Builds test-server image (parallel)
- docker-proxy: Builds proxy image (parallel)2. Created reusable-javadoc.yml workflow:
- Eliminates duplication between deploy.yml and publish-javadoc.yml
- Handles module organization and cache-busting
- Supports optional json-doclet profile
- Used by deploy.yml for standard javadoc generation3. Optimizations:
- Build JARs once, reuse via artifacts in all jobs
- Base image verification moved to just before each Docker build
- Fluxzero registry login only in proxy job (not test-server)
- Fail fast: If build/test fails, no other jobs run4. Updated publish-javadoc.yml:
- Kept inline due to GitHub Packages authentication requirement
- Added safety check for module directories
- Maintained json-doclet profile supportBenefits:
- 50% faster deployments
- Better resource utilization
- Clear job separation and failure isolation
- Maintains all existing functionality* ci: make reusable javadoc workflow manually triggerable
Enable reusable-javadoc.yml to be triggered manually via workflow_dispatch
while maintaining its use as a reusable workflow. This eliminates the need
for a separate publish-javadoc.yml workflow.Changes:
1. Added workflow_dispatch trigger to reusable-javadoc.yml:
- Can now be manually triggered from GitHub UI
- Includes toggle for json-doclet generation
- Configurable modules and destination directory2. Unified input handling:
- workflow_call: uses include-json-doclet and maven-profiles inputs
- workflow_dispatch: uses enable-json-doclet toggle
- Dynamic configuration step normalizes inputs for both modes3. Conditional GitHub Packages authentication:
- Only authenticates when json-doclet is enabled
- Automatically configured based on trigger and inputs
- Runs mvn install before site generation when json-doclet needed4. Removed publish-javadoc.yml:
- No longer needed - functionality moved to reusable workflow
- Reduces maintenance burden
- Single source of truth for javadoc generationUsage:
- Automatic: Called by deploy.yml for standard javadoc (no json-doclet)
- Manual: Trigger from Actions tab, optionally enable json-doclet* ci: rename reusable-javadoc.yml to javadoc.yml
Simplify workflow naming since it's now both reusable and manually
triggerable. Updated reference in deploy.yml.* fix: run json-doclet as part of site instead of verify
* ci: clarify Maven setup with separate steps for GitHub Packages auth
Replace conditional server-id/username/password parameters with two
separate, explicit Java setup steps for better clarity.Changes:
- Separate 'Install Java and Maven (standard)' step for normal use
- Separate step with GitHub Packages authentication for json-doclet
- Clear step names explain when each is used
- Removes confusing conditional empty string parameters
- Makes it obvious that server-id 'github' is for Maven repository auth* ci: always enable json-doclet in javadoc workflow
Simplify javadoc workflow by always generating JSON documentation
instead of making it optional. This removes unnecessary conditional
logic and ensures JSON docs are always up-to-date.Changes:
- Removed enable-json-doclet toggle from workflow_dispatch
- Removed include-json-doclet and maven-profiles inputs from workflow_call
- Removed conditional configuration step
- Always set up GitHub Packages authentication
- Always run mvn install to fetch json-doclet dependency
- Always use -Pjson-doclet profile
- Always include json-doclet output in published docsBenefits:
- Simpler workflow (124 lines → 82 lines)
- No conditional logic to maintain
- JSON docs always available
- Consistent behavior for all triggers