Build app instead of using prebuilt artifact

[Salamandar]

Problem

• Prebuilt artifacts are built for root install cinny.mydomain.tld/, not subpath mydomain.tld/cinny
• For subpath, you need to configure the build system, then build Cinny. This takes ~4GB of RAM, thus excluding low-RAM instances.

For now subpath install is disabled, but /shrug

[tituspijean]

My conclusion: building Node apps requires a ridiculous amount of RAM, and is not self-hosting-friendly.

[oleole39]

I read the issue filed upstream: cinnyapp/cinny#1843

If the mismatch with prebuilt releases is only to be found in the hyperlinks in index.html, could we as a workaround simply make absolute path be relative using sed (or ynh_replace) after ynh_setup_source ? Or would it leave other issues ?

EDIT3: removed inaccurate stuff of the 2 previous edits

[oleole39]

Just made a little test which seemed successful (I was able to log into Matrix and display last messages) :

• in ./assets/index-Atzb1wkb.js replace const t=`${zi("/")}/config.json`; with const t=`${zi("./")}/config.json`;
• in index.html replace:
  • /assets with ./assets
  • /manifest.json with ./manifest.json
  • cinny.in/? with $domain$path (interrogation mark as regex, and domain & path as variables provisioned by YNH core)

I can send a PR if you wish.

[oleole39]

By the way, regarding upstream - i wonder whether there could be an issue in defining base url as ./ instead of / ?

[Salamandar]

I can send a PR if you wish.

Oooh please do ! we'll run tests and check at home ;)

[Salamandar]

The thing is that patching the built sources might break in a future cinny version… the danger is giving more work for our future ourselves

[oleole39]

The thing is that patching the built sources might break in a future cinny version… the danger is giving more work for our future ourselves

Hmm yes however:

1. So far the amount of post-built customizations is reasonable (2 files modified).
2. The only alternatives to avoid local build and make it work properly with YNH given upstream answer to your issue is that someone builds it and then uploads it to Github (I'm more comfortable with post-built customizations given the previous point)... until that day: Create a build system based on yunorunner so that app can pre-build artefacts later used for installs YunoHost/issues#1851

[oleole39]

I can send a PR if you wish.

Oooh please do ! we'll run tests and check at home ;)

Hmm I've started working on a PR, but for some reasons I can't reproduce my "success" of the other day... Or it would take quite many more ynh_replace_string than expected.

Details

• When Installing my test package via YNH, Cinny URL (even when permission is granted to the visitors group) sends me to YNH SSO login page. If I log in SSO, clicking on the Cinny tile goes briefly (1-2s) to a blank page and then comes back to the tiles menu (could that be a nginx issue?).
• I also tried on a non-YNH server (where I had my quick success last time). Copied my customized Cinny folder in a subdir, and here at least the page display but blank with an error message triggered by one of Cinny's JS file ("Page not found"). I can see in the network dev tools that some resources are still trying to be accessed at the wrong path. After some more tweaking, all resources are being loaded, i see briefly (1-2sec) the usual "heating up" loading screen, and then it goes back to a white page (not blank - source code shows the content of Cinny's index.html - so that's JS-related...).
  If I compare to your last working version installed on a YNH subdomain's root, I notice that all local ressources are called and found in both cases, but in my test version there are no call made to the Matrix server (say matrix.org).

So i've turned to that build script which sets base path to a placeholder subdir (__YNH_SUBDIR_PATH__) that can then be easily replaced in the install/upgrade scripts. Install/update scripts would download the release hosted on YNH repo, and would then ynh_replaced the placeholder with $path in 3 files:

• index.html
• assets/index-{*1}.js, where {*1} is a random string which changes at each build - not very convenient as the dir contains several files named with the same format, but basically it can be spotted as the second heaviest js file of the dir.
• assets/index-{*2}.css, where {*2} is another random string, but there's only one file of that format.

PR is there, and it should now be added the correct source both in manifest.toml and in ynh_setup_source. I believe there should be 2 sources in the manifest:

• upstream so that autoupdate stragegy keeps being triggered
• custom prebuilt asset which would be the one used with ynh_setup_source in install/upgrade scripts.

I haven't tested the upload part of the build script so far, but I expect it to work once appropriate token is filled in as I took it from that script from @Josue-T.
Could that be run via Github Actions of the cinny_ynh repo until YNH infra handle such build scripts ? Maybe it could be triggered when it detects the new PR created by YNH infra with regards to the autoupdate strategy ?

[oleole39]

Could that be run via Github Actions of the cinny_ynh repo until YNH infra handle such build scripts ? Maybe it could be triggered when it detects the new PR created by YNH infra with regards to the autoupdate strategy ?

Implemented there #75

[oleole39]

Re-implemented in PR #98. Subpath install can now be successfully tested when installing from https://github.com/oleole39/cinny_ynh/tree/prebuilt_with_subpath_support