ammachado commented on PR #24754:
URL: https://github.com/apache/camel/pull/24754#issuecomment-4993023244

   On the dual exe compilation (thanks @davsclaus): I looked at reusing the 
`camel-exe` artifact in `camel-launcher-native`, and it turned out the exe 
compile wasn't where the time was going. The exe is a ~100-line static C file, 
so each cross-compile is a sub-second clang call. Reusing that specific 
artifact across jobs would mean uploading both classifiers, downloading and 
`install:install-file`-ing them, and splitting the single `camel.exe.build` 
property that currently drives the compile, the copy-into-launcher, and the 
release gate together. That is a fair bit of coupling to shave off a couple of 
seconds.
   
   The real cost in that job was `-am` rebuilding the whole launcher reactor 
(camel-core, the jbang tree, and the rest) from source. So I dropped `-am`: 
`camel-launcher-native` now builds only `buildingtools`, `camel-exe`, and 
`camel-launcher`, and resolves the launcher's other in-repo modules as the 
current version's snapshot from Apache snapshots. That takes the job from ~10 
min down to a couple. A preflight step checks that snapshot tree is actually 
published (using `camel-launcher` itself as the sentinel, since it is deployed 
after its dependencies) and fails early with a clear message if it is not, so a 
version-bump window reads as "snapshot not deployed yet" rather than a deep 
resolution error mid-build.
   
   While in there I also moved both exe jobs off mvnd to plain `mvn`. With the 
smaller reactors the daemon bought no parallelism, and its cold-start was 
intermittently timing out, which was the earlier `camel-launcher-native` 
failure.
   
   One tradeoff worth calling out: the launcher packaging check now trusts 
Apache snapshots for its unchanged upstream modules instead of building them 
from source. Since this workflow only triggers on `camel-exe`/`camel-launcher` 
changes, those upstream modules are identical to main, so it validates the same 
bytecode either way. Happy to reconsider if you would rather keep it hermetic 
with `-am`.
   
   _Claude Code on behalf of @ammachado_
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to