Conversation
The vanagon packaging under packaging/ will build the uberjar without ezbake, so add pkg and pkg-fips profiles for that build. The pkg-fips profile leaves every BouncyCastle class out of the jar because the FIPS packages install the BC FIPS jars next to it instead. Add packaging group to the Gemfile. The packaging gem pin is commented out because it conflicts with the packaging version vanagon's gemspec requires, and the Rakefile's use of it has been commented out for a while. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
These are the CLI machinery and subcommands, the configuration files, bootstrap.cfg, java.security.fips and the 8.x wrapper scripts exactly as ezbake renders them into the shipped openvox-server packages, taken from the 9.x and 8.x packages. Keeping them in the repo makes the package contents reviewable here instead of being generated at build time. Two things differ from the shipped copies. The version line in bin/puppetserver has a @@Version@@ placeholder that the vanagon build fills in, and the wrapper helper is renamed from ezbake-functions.sh to helper-functions.sh because ezbake is no longer involved. The wrapper scripts that source it are updated to match. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
Two vanagon projects replace the ezbake build. openvox-server-uberjar builds the uberjar and the vendored gems once per variant, on el-9 for the regular jar and on redhatfips-9 for the FIPS jar, and publishes the installed tree as a rooted archive rather than a package. openvox-server builds the noarch rpm or deb for one platform. Its uberjar-tarball component unpacks that archive and its openvox-server component installs the authored content from resources/files and the rendered unit, defaults file and cli-defaults.sh. The JDK and leiningen are installed inside the build container, with the lein script and standalone jar pinned by checksum. The platform to variant mapping, the archive naming and the Clojure dependency rebuild knobs live in lib/server_packaging.rb so the rake tasks and the vanagon configs share one definition. Both service styles from the ezbake packages are kept and chosen by major version. The direct style matches the ezbake 4.x units shipped for 9.x, with Type=notify-reload where the platform's systemd is new enough and the FIPS jars directory on the classpath. The wrapper style matches the ezbake 2.x packages shipped for 8.x. Deviations from the ezbake packages: install.sh and ezbake.manifest are no longer shipped, the deb enables the service on a fresh install, purging the deb no longer removes the log directory, the log directory is 0700 on rpm platforms, the Fedora dist tag is fcNN, and the 8.x wrapper helper is installed as helper-functions.sh. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
When run locally, building openvox-server first builds the uberjar archive it needs when that is missing from packaging/output and then points vanagon at that directory. In CI, the uberjar job has already uploaded the archive, so the project falls back to the artifacts bucket URL. The version helper mirrors vanagon's version_from_git so the archive name computed here matches the one vanagon computes for the same ref. vox:upload uploads the vanagon output for one platform. Packages have the short platform tag in their names while the uberjar archives carry the full vanagon platform name, so the filter accepts either. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
The workflow calls the shared build_vanagon.yml twice. The first call builds the openvox-server-uberjar project on its two fixed platforms and always uploads the archives, because the second call, which builds openvox-server for every platform in the server-vanagon list, fetches them from the artifacts bucket. This depends on the platforms_key input and the server-vanagon lists in shared-actions. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
Not used, and conflicts with vanagon currently. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com>
Member
Author
|
I think this is currently broken for building FIPS. I'll debug that tomorrow. Edit: Fixed via OpenVoxProject/vanagon#98 |
bastelfreak
reviewed
Sep 17, 2026
Member
Author
|
This also does not yet create the openvox-server tarball that @smortex needs for FreeBSD builds. Will push up a commit with that next. |
Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com>
The ezbake build created openvox-server-<version>.tar.gz next to the packages, and the FreeBSD port fetches that tarball from the artifacts bucket to build its own package. It takes the jar, the configuration files, bootstrap.cfg, the CLI dispatcher and subcommands and cli-defaults.sh from under a puppetserver-<version> top level directory. The openvox-server package build already has all of those in place, so on one platform its openvox-server component also assembles that layout and writes the tarball into output/, where vanagon copies it back next to the packages and vox:upload publishes it under the same name as before. A build_requires on the uberjar-tarball component only orders the two components so the jar is unpacked first. The tarball is built with reproducible tar flags from SOURCE_DATE_EPOCH. Signed-off-by: nmburgan <13688219+nmburgan@users.noreply.github.com> Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
context On a default installation the primary should be able to clean its own code cache https://github.com/OpenVoxProject/openvox-server/pull/640/changes Signed-off-by: Marcus Poller <marcus.poller@betadots.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds all the machinery to build openvox-server packages with vanagon instead of ezbake. It does not yet remove the extraneous ezbake machinery.
There are two stages. First, a tarball containing the uberjar, vendored gems, and FIPS BC jars for FIPS builds is created. Then, this is used by the openvox-server project to then package these up with the service files and CLI files. This is two stages because the uberjar and related files are not platform-specific, so it would be a waste to compile this every time for every platform.
Requires OpenVoxProject/shared-actions#149 for building in GHA