Project

General

Profile

Actions

Task #3545

closed

Automate and finish the setup of the Jenkins WASM tinderbox

Added by Jan-Marek Glogowski 10 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Team - Q1/2022
Start date:
Due date:
% Done:

0%

Tags:

Description

The goal is to have a tinderbox, which builds the feature/wasm branch, deploys a package to the "daily builds" directory and serves the latest WASM build statically. This webserver can easily be separate from the TB.

Now that LODE is patched to setup the WASM build environment, a few steps are needed for an automated setup via Salt:

Lode changes for WASM

  • lode/init.sls
    • lode-pkg eventually needs wget
    • No libreoffice build dependencies are needed
    • Default branch is feature/wasm
    • setup needs the additional option --wasm-local

Static webserver setup

  • nginx/*
    • See https://doc.qt.io/qt-6/wasm.html ; search Multithreading
    • Two additional headers must be served for thread support:
      • add_header Cross-Origin-Opener-Policy same-origin
      • add_header Cross-Origin-Embedder-Policy require-corp
    • https is needed for the browser clipboard API
    • mime.types should contain an entry for application/wasm wasm; to enable browser caching.

For the actual build we need to:

  • source ${LODE_HOME}/emsdk/emsdk_env.sh
  • export QT5DIR=${LODE_HOME}/qt5/qtbase
  • Run autogen.sh --with-distro LibreOfficeWASM32 (AKA --host=wasm64-local-emscripten)
  • Run make

All the required files can be bundled via:

tar -chf wasm.tar --xform 's/.*program/lo-wasm/' instdir/program/soffice.* instdir/program/qt*

FYI: this includes the file `qtlogo.svg`, which is shown while downloading the data before running the WASM app. Obviously this can be easily be replaced with whatever "branding" we want to display on load ;-)

For a debug build xz saves ~1/3 compared to gzip.

Eventually one might rename qt_soffice.html to index.html

Actions #1

Updated by Jan-Marek Glogowski 10 months ago

  • Description updated (diff)
Actions #2

Updated by Florian Effenberger 9 months ago

  • Assignee set to Christian Lohmaier
  • Target version set to Q4/2021

Seems there was some confusion around this ticket. I've talked to Guilhem and Cloph, let me try to summarize (and Cloph, please correct me if I write something wrong :).

Happy to provide a box or two, of course - sorry for the delay on this.
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.

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.
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.

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?

Actions #3

Updated by Jan-Marek Glogowski 9 months ago

  • Description updated (diff)
Actions #4

Updated by Jan-Marek Glogowski 9 months ago

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.

Actions #5

Updated by Christian Lohmaier 9 months ago

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

Actions #6

Updated by Christian Lohmaier 9 months ago

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,$@)

and thus it fails since the sample document (android/default-document/example3.odt) is in SRCDIR, not in BUILDDIR.

Actions #7

Updated by Florian Effenberger 8 months ago

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

Actions #8

Updated by Florian Effenberger 7 months ago

  • Status changed from New to Closed

Seems to work fine, just talked to Cloph - closing here

Actions #9

Updated by Jan-Marek Glogowski 6 months ago

  • Description updated (diff)

Firefox has a setting to show additional information about WASM processing in the developer tools console in about:config: javascript.options.wasm_verbose

This should show at best WebAssembly verbose: async instantiate succeeded (loaded from cache). For The wasm-test side, at least the (loaded from cache) is missing. That is happening, because WASM files should return application/wasm as a mime type; currently it's the default binary blob application/octet-stream.

Actions #10

Updated by Jan-Marek Glogowski 6 months ago

  • Description updated (diff)
Actions #11

Updated by Florian Effenberger 6 months ago

  • Target version changed from Q4/2021 to Q1/2022

Cloph, something for you or hand over to Guilhem for web server
configuration?

Actions #12

Updated by Christian Lohmaier 6 months ago

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

Actions

Also available in: Atom PDF