Infrastructure

Florian Effenberger wrote in #note-2:

From what I understand, you currently need a box that you can manually tweak in production and configure, change settings etc., so nothing that (yet) can go into SaltStack for deployment, as any of your changes would be quickly overwritten by SaltStack.

FWIW: the described setup should work right now with SaltStack. It should be an automated TB, installed with the described Salt modification with the LODE setup and without any manual tweaks. We know we can build LO WASM via LODE. And actually I would want to have two TBs at some point: one for a debug build, one a production build. If one is working, the 2nd is basically a clone. The difference is just a single flag to autogen.input: --enable-dbgutil. This box can be completely internal (AKA just reachable via SSH jumpserver).

But as a start / currently: we need to update LODE more or less often. I found that Qt WASM in any branch is much buggier then any binary Qt build, even basic stuff :-( So a developer (and any TB) will need to patch Qt "somehow". Also Emscripten doesn't have something like a stable branch. I don't know how often LODE is updated on TDF boxes, so for the time being the already provided box seems better. I currently patch Qt WASM daily and even Emscipten :-( Windows ARM64 is much more stable…

Buildbots/tinderboxes are behind the VPN and not publicly accessible, so they can stay out of deployment and can be tweaked manually as you wish, but they are only accessible internally with the VPN.

That is fine. As I wrote we just need a static web server to deploy the result, which means my provided packaging command. Then copy that package to the daily repo and unpack it to the static web server. I've described the needed ngnix setup in the ticket text. We just need to define, how that data transfer will happen.

If the box is public-facing, we need some sort of deployment in the long run, to manage the machines, which limits the amount of manual tweaks.

The pubic-facing web server is just that: a web server with https and two additional headers for responses. It just serves static downloads from a single directory (or two directories for release and debug builds).

Proposal therefore: We can provide a box (either VM or Hetzner-hosted) you can play with, when it is fully tweaked, we then reinstall and turn into a salted machine, and/or split into two different machines (one salted public box, one non-salted behind VPN).

Would that work for you?

Yup. Separate boxes, like your 2nd proposal for web server (public, Salt'ed) and the TB (hidden, currently manual) would generally be my preference too. I don't know if a real, extra web server box is needed or you an expand some existing box, like the download sever (if it's not a CDN), but that is completely up to infra. There is no need to expose the TB to the web.

So in addition: the Salt'ed web server automatically updates it's deployment / serving directory from the daily build directory once an hour. TB's already fill an upload directory, so some mechanism must already exist and work. This just needs some coordination. On that already provided box, we can run a cron'ed TB job on for the time being.

FYI: setup cannot be deployed on the centOS baseline, the upstream binaries require glibc 2.18, while CentOS 7 only has 2.17 - so will keep in on the ubuntu machine for now.

Also there's another problem that the build fails with --enable-werror (which is set by configure.ac when LODE_HOME is set, which is the case for the regular jenkins configuration) in the added lockfile tool (and maybe other places). Can add a workaround for the build job though, but ideally should be fixed in the branch so it can build with --enable-werror

test-webhost at https://wasm-test.libreoffice.org/ however there's another build issue, namely that its not possible to build in builddir != srcdir

static/CustomTarget_wasm_fs_image.mk simply disregards the prefix when creating the filelist for the packaging command:

$(wasm_fs_image_WORKDIR)/soffice.data.filelist: $(gb_wasm_image_filelist) | $(wasm_fs_image_WORKDIR)/.dir
        TEMPFILE=$(call gb_var2file,$(shell $(gb_MKTEMP)),1,$(subst $(SRCDIR)/,,$(subst $(BUILDDIR)/,,$^))) && \
            mv $$TEMPFILE $@.tmp
        $(call gb_Helper_replace_if_different_and_touch,$@.tmp,$@)

Jan-Marek: Anything else needed from our side, is all working for you?

added the mime type (FYI: chrome still doesn't cache the file, but works for firefox now)