davsclaus opened a new pull request, #29428: URL: https://github.com/apache/camel/pull/29428
JIRA: [CAMEL-26748](https://issues.apache.org/jira/browse/CAMEL-26748) **Stacked on #29427** (the `camel doctor` fix for the web installer, which this needs: with nightly builds, a release and a nightly build often sit side by side). Review only the last commit; I will retarget this PR to `main` once #29427 is merged. Today `camel self-update` and the web installers only install releases. To try the latest development code, or a fix before its patch release, you have to build Camel yourself or switch to a JBang install. Apache already publishes a nightly `camel-launcher` build, with the same `bin.tar.gz` the installer uses, to the snapshot repository, for main and the maintenance branches (today 4.24.0, 4.22.3, 4.18.6 and 4.14.10-SNAPSHOT). ``` camel self-update --version SNAPSHOT # the newest nightly build of main camel self-update --version 4.22.3-SNAPSHOT # the newest nightly build of a maintenance branch camel self-update --version LTS # back to a release (or --version X.Y.Z) curl -fsSL https://camel.apache.org/install.sh | sh -s -- --version SNAPSHOT ``` ``` $ camel version Camel CLI version: 4.24.0-SNAPSHOT Nightly build: 4.24.0-20261108.143653-24 (built 2026-11-08 14:36:53 UTC) ``` ## Changes - **Selectors and pin.** `install.sh` and `self-update` take `SNAPSHOT` (main: the highest `X.Y.Z-SNAPSHOT` in the repository, not `<latest>`, which names whatever deployed last) and `X.Y.Z-SNAPSHOT`, and record it as the pin, so a later `camel self-update` installs the newest nightly build. `self-update` hands the installer the exact nightly build it resolved (`4.24.0-20261108.143653-24`), as it already does for releases. An explicit release `--version` leaves the nightly builds and removes the pin. An exact pin still refuses to move, and an `X.Y`/`LTS` pin still refuses an explicit `--version`. - **One directory per nightly build.** A nightly build keeps its version with new content, so installing it over `versions/4.24.0-SNAPSHOT` would pull the jars from under a running `camel tui`. Each build gets its own directory, named after it. The installer keeps the three newest nightly builds and never removes a release. - **Resolving the build.** From the `maven-metadata.xml` of the snapshot repository. The repository runs Nexus 2.15, which serves the Maven 3 metadata (with `<snapshotVersions>`) to curl, but the older Maven 2 form (only `<snapshot><timestamp>` and `<buildNumber>`) to the JDK HTTP client, and possibly to wget. Both forms are read, in Java and in `install.sh`. I only found this in the end-to-end run against the real repository. - **Checked before use.** The build name from the metadata goes into a directory name and a URL, so it must match `X.Y.Z-YYYYMMDD.HHMMSS-N` and belong to the requested version, or the install stops before downloading. The XML parser is the JDK's own, with DTDs and external entities disabled (an old Xerces on the class path does not know the JAXP 1.5 properties). - **Verification.** Against the `.sha1` published next to the archive. This is weaker than for a release (a SHA-256 in a manifest on camel.apache.org, a different server than the download): it catches a broken download, not a tampered one. A note says so, and that a nightly build is a development build, not an Apache release. - **No update notice** for a pin to nightly builds: a new build lands every day. - **`camel version`** shows the nightly build and when it was built, on its own line (scripts may parse the `Camel CLI version:` line). The jars carry the fixed reproducible-build timestamp, so the file dates on disk do not tell. - **Docs.** A "Nightly development builds" section on the launcher install page, with the ASF caveat. It is deliberately not linked from Getting Started: ASF release policy says not to promote nightly builds to the general public. ## Not in this PR - `install.ps1` (Windows) does not install nightly builds yet; I had no PowerShell to test it. - `self-update` downloads `install.sh` from the website, so nightly builds work once the website publishes the new script. ## Tests Stacked PRs get no "Build and test" run, so these are local runs (with `XDG_DATA_HOME` unset, see below): - `WebsiteInstallTest` (91, 12 Windows ones skipped), `SelfUpdateIntegrationTest` (23), `ManifestFetcherTest` (40), `PinTest` (26), `NightlyTest` (13), `UpdateCheckerTest` (15), `SelfUpdateCommandTest`, `UpdateCheckRefreshTest`, `CamelLauncherTest`, and in camel-jbang-core `DoctorTest`, `InstallDetectorTest`, `VersionGetTest`: all pass. - New installer tests cover each selector and its pin, a wrong SHA-1, malformed builds in the metadata (`../`, another version), the Maven 2 metadata, pruning, and going back to a release. - End to end against the real Apache snapshot repository, in a sandbox home: `install.sh --version SNAPSHOT` and `--version 4.22.3-SNAPSHOT` install and run the real nightly builds; with the launcher of this branch, `camel self-update --check` and `camel self-update` move to the newest nightly build, and `camel doctor` marks it active. The existing self-update tests read `XDG_DATA_HOME`: when it is set, they look at the real install of the machine and fail. Not changed here. _Claude Code on behalf of Claus Ibsen_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
