feat: build for OpenVox 9

[d1nuc0m]

Short description

Start building containers for OpenVox 9. First attempt at containers, there will be changes to do.

Checklist

I have:

• read the CONTRIBUTING.md document
• read and accepted the Developer Certificate of Origin document and added a Signed-off-by annotation to each of my commits
• read and accepted the AI Policy document and added Generated-by or Assisted-by annotations to each of my commits created with the help of an AI agent
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[d1nuc0m]

Apparently it builds. Because release candidates use - in filenames and ~ in URLS (and I guess it'll happen in the future) I added a parameter and steps that override the download folder in the URL

[MirandaStreeter]

Testing it out locally and I'm running into issues. It looks like RUBYGEM_OPENVOX is shared between the two releases, which I believe is what killed #223's CI. We'll want to separate the two somehow.

[MirandaStreeter]

So, we push to main, it triggers the create-multiarch-manifests job, but the "floating" tags look like it'll pull whatever was finished last? I think? What determines which will be marked as latest and latest-alpine? I might just not understand the logic flow.

[d1nuc0m]

We'll want to separate the two somehow.

That should now be taken care of by rubygem_openvox

What determines which will be marked as latest and latest-alpine? I might just not understand the logic flow

Should be fixed, floating tags are updated conditionally now

[d1nuc0m]

@MirandaStreeter should work now

[MirandaStreeter]

It consistently builds now. But it looks like you're updating the github workflow files directly. These are managed files. For example, at the top of ci.yml it says:

# Managed by modulesync - DO NOT EDIT
# https://voxpupuli.org/docs/updating-files-managed-with-modulesync/

In short, the ci.yml file in this repo is a merging of .sync.yml, and the voxpupuli/modulesync_config repo's ci.yml.erb template, as well as the default settings in config_defaults.yml.

I'm pretty sure the next time any kind of workflow runs on the modulesync_config repository a modulesync is triggered across the org, and some of your build-args will be overwritten (along with some other bits, if I'm reading this correctly.) We'll want to move some of the settings from here to there.

Apologies if this is adding a lot of complexity. I always have to re-review how this rube goldberg machine works myself.

[d1nuc0m]

In short, the ci.yml file in this repo is a merging of .sync.yml, and the voxpupuli/modulesync_config repo's ci.yml.erb template, as well as the default settings in config_defaults.yml.

Ok, tried to moved changes there with a separate commit to keep track of changes (should be squashed at merge time). How am I supposed to correctly "merge" them now? The CI is back to its previous state

Also removed the workaround for Release Candidate URLs

[MirandaStreeter]

You'll want to follow the instructions outlined here:
https://voxpupuli.org/docs/updating-files-managed-with-modulesync/

At the root of this repository, is a directory named moduleroot which contains all the templates used to generate the files ModuleSync manages. Create a PR against the modulesync_config repository to make changes to files managed by ModuleSync.

If your changes do not apply to all modules managed by Vox Pupuli, add a toggle key with a sane default in the config_defaults.yml file at the root of the repository and use @config['your_custom_key'] to tune the templates expansion. Then, in the modules that should use this feature, update the setting accordingly in the .sync.yml file at the root of the module.

For a complete example, see this commit to the modulesync_config repository which manage a few files and introduce 3 tunables:

voxpupuli/modulesync_config@7583664

For the finer details I think the #voxpupuli channel in Slack/IRC would be a good spot to ask, or the mailing list if posterity is important.

[bastelfreak]

that sounds like an ezbake bug that we should fix

[rwaffen]

does the server start without it? i can remember having some problems with it if missing 🤔

[MirandaStreeter]

I built the image locally (both ubuntu and alpine), and ovxserver 9 starts without it (or at least the healthcheck).

Only tweak might be the comment, should be "Not present in ezbake 4, necessary for OpenVox 8".

[d1nuc0m]

Done

[d1nuc0m]

@MirandaStreeter I was able to make it work

[MirandaStreeter]

Perfect, moving the parameters to .sync.yml works, thanks. I would personally prefer if the latest tag wasn't a number in a condition (matrix.release=='9') so that that we don't have to remember to update it when OVX10 releases, but that can be separate, and not even a big deal. Works on my machine. I don't see any blockers.

But before releasing I'd like one more set of eyes, considering this is a major bump. @rwaffen?

[rwaffen]

LGTM, but not sure about the missing ezbake-functions.sh

[d1nuc0m]

not sure about the missing ezbake-functions.sh

Me too, I just took the content of the .tar.gz artifact as good

[d1nuc0m]

@rwaffen @MirandaStreeter

I quote from IRC/Slack @Sharpie

> is the missing ext/ezbake-functions.sh  a bug or a feature in ov9?
It is intentional. It was removed as part of the re-factor to run the process directly under SystemD: https://github.com/OpenVoxProject/ezbake/issues/13

Relevant PR: https://github.com/OpenVoxProject/ezbake/pull/25/changes