Preferred app source selection for YNH packages

[Supbol]

Hello,

I have read several time that YNH install scripts must favor prebuilt releases to save resources on small machines.

Hence those questions:

1. At which point should building locally be considered as too demanding in terms of resources so that an alternative source is preferred?

2. Is there an order of preference established between:

• Build locally from forge’s repo
• Build on a YNH contributor’s machine and distribute as prebuilt release on YNH package repo (cf. Josue-T work for synapse_ynh);
• Download prebuilt releases from forge’s repo;
• Docker image extract (and what image should be downloaded ? the one counting most downloads/stars in Docker Hub’s listing?);

[Aleks]

I don’t see any situation in which building locally should be preferred over using a prebuilt version

If you compare to apt : apt install foobar installs a pre-built version of the package. Nobody cares (except nerds or whatever) about compiling every program locally, it simply doesn’t make sense, except in advanced threat models, which YunoHost is not about.

In an ideal world, every app would provide pre-built versions of their app. The big question is that many do not, and therefore where do we put the tradeoff between building locally on users machine versus investing time into creating our own build chain somehow (which the upstream project should handle, not us).

@Supbol

Docker image extract (and what image should be downloaded ? the one counting most downloads/stars in Docker Hub’s listing?);

Docker image can be seen as sort-of a prebuilt using the docker format rather than a classic zip/tar … I don’t know what you mean by “what image should be downloaded”, i don’t think there’s much ambiguity assuming the upstream project provides a prebuilt image. (And yeah it’s not like we should trust docker image from third party that are not the official upstream I guess ?)

[Limezy]

Just to add to the conversation, I have one package for which some features would be broken if it wasn’t built locally. Indeed, I had to integrate a few tweaks for it to work with Yunohost internal mailing system for instance.

Of course, the best would be to pre-build it myself (or with some kind of automated YNH tool) for each target architecture and then have the package to be a pure executable downloader, but that’s something I’m not able to do as of today.

[Supbol]

Thank you for the detailed answer @Aleks. From it I assume the following order of preference:

1. Download prebuilt releases from forge’s repo;
2. Docker image extract (if an official image is available);
3. Build on a YNH contributor’s machine and distribute as prebuilt release on YNH package repo (cf. Josue-T work for synapse_ynh);
4. Build locally from forge’s repo

Docker image can be seen as sort-of a prebuilt using the docker format rather than a classic zip/tar … I don’t know what you mean by “what image should be downloaded”, i don’t think there’s much ambiguity assuming the upstream project provides a prebuilt image. (And yeah it’s not like we should trust docker image from third party that are not the official upstream I guess ?)

Yes, in some cases, the upstream project may provide a Dockerfile but no official image on Docker Hub. There is no point to building the Docker image locally in YNH I assume. However there are generally some community images available on Docker Hub (that may nevertheless not be affiliated with any of the project’s contributors). Those can be ranked either by “Best match” (I assume this relates to the number of downloads and/or number of time the image was set as a favorite) or by “Recently updated”. Should it be considered as fine to use a community image for a YNH package when there is no official image available, I guess we should go for the most popular one provided that it has been updated recently enough to match among the last versions of the app. But yes, should such third-party image be trusted?

Similarly, an upstream project can have no prebuilt release and no Dockerfile, but exists as a Docker Community Image (again, not affiliated whatsoever to the upstream project contributors). Should however (2) with Community Image still be a preferred source option for the YNH package over (3) or (4) ?

Eventually, there are the cases when there would be no Docker image available (neither official nor third-party) or, as reported by @Limezy, when the YNH package requires a custom build, i.e. no other choice than opting for options (3) or (4). I’ve stumbled upon that particular Github issue which serves as an example to Limezy’s point.

the best would be to pre-build it myself (or with some kind of automated YNH tool) for each target architecture and then have the package to be a pure executable downloader

Actually the YNH CI is already building those packages (maybe not for all arch though). I don’t realize how much work it would take, but an interesting feature for YNH infra would indeed be that on a successful test, the CI zips the compiled files and uploads it to the YNH package’s release section.
For instance, !releaseme could trigger the CI to test the package and in case of success, it would check for a text file at the root of the YNH package’s repo (such as release.ynh) specifying a list of files or folders to zip/tar and then upload that archive to the release section of the repo and prefill the manifest.toml source URL.
In install/upgrade script, we would add a build section to be executed only when a source is not defined in the manifest (that could be implemented with a single bash condition or as YNH core feature).
In the order of preferred sources, it would become the new (3), with current (3) and (4) becoming respectively (4) and (5) (and actually (5) may have no more practical use case?).

[Aleks]

@Supbol

Yes, in some cases, the upstream project may provide a Dockerfile but no official image on Docker Hub. […] should such third-party image be trusted?

Urhg yeah didn’t realize that … I don’t know either if the 3rd party images should be trusted, I think if I stumbled on an app using a 3rd party docker image I would very much be uncomfortable because 1) (security tin foil hat mode) that 3rd party could backdoor the image or 2) there’s no guarantee that 3rd party will keep the image up to date ? I don’t know …

@Supbol

the YNH CI is already building those packages (maybe not for all arch though). I don’t realize how much work it would take, but an interesting feature for YNH infra would indeed be that on a successful test, the CI zips the compiled files and uploads it to the YNH package’s release section.

Yeah there’s a mid-term / long-term idea to design such a system, cf Create a build system based on yunorunner so that app can pre-build artefacts later used for installs · Issue #1851 · YunoHost/issues · GitHub

Though that requires careful design and in the end it’s also very “meh” because again, in an ideal world, the upstream project would handle the build, otherwise that increases the resources needs to run our infra, we start being sort of yet another “hub”, maybe people outside yunohost would start using our builds etc… but i guess we ain’t gonna cut it if we really want to address the fact that people shouldnt have to build apps locally…

[Supbol]

@Aleks

1. (security tin foil hat mode) that 3rd party could backdoor the image or 2) there’s no guarantee that 3rd party will keep the image up to date ? I don’t know …

1. Well as a general rule, I would incline to the view that the more intermediaries, the higher the risk… Now some Docker packagers may have good track record… But what could be simple track record indicators to be considered by YNH package managers (are large number of download, many stars within Docker Hub community, and currently up to date image enough?).
2. This appears secondary to me - somehow that’s just another theoretical possibility for a YNH package to be broken. That may not be an issue provided YNH app maintainer is still around if it actually breaks at some point but also if he/she is aware of it. To spot automatically such situation, currently the infra opens a PR when a new version is there as compare to upstream forge repo, thus attracting attention of the maintainer. Nevertheless it doesn’t mean the PR can be merged - the maintainer should check whether a new docker image is available.
   Not sure how worthy it will be given that checking that point is quick to do manually, but it could also be automatized with a new manifest entry such as dockerhub = account/repo allowing infra to retrieve last_updated value from curl -X GET https://hub.docker.com/v2/repositories/{account/repo}/tags/?page_size=1&page=1&ordering=last_updated and compare dates… as unfortunately Docker Hub seems to have a versioning system totally decorrelated from upstream.

Nice to read the CI-related idea is already somewhere in the pipe.