deblob Pleroma #1285

Open
opened 2019-09-30 13:11:19 +00:00 by kaniini · 4 comments
Member

Pleroma presently ships several blobs:

  • Pleroma FE
  • our packaging of GlitchSoc, MastoFE
  • Admin FE

We generate artifacts for all of these with CI already.

We should change the installation process to optionally download and install these components as requested, instead of carrying them as blobs inside the main repo.

Pleroma presently ships several blobs: * Pleroma FE * our packaging of GlitchSoc, MastoFE * Admin FE We generate artifacts for all of these with CI already. We should change the installation process to optionally download and install these components as requested, instead of carrying them as blobs inside the main repo.
Owner

I guess it essentially means reusing installation/download-mastofe-build.sh for this, the script can be made more generic by allowing the user to pick a frontend and optionally a version, otherwise I guess it could be ported to Elixir by reusing what is done for the emoji packs.

I guess it essentially means reusing `installation/download-mastofe-build.sh` for this, the script can be made more generic by allowing the user to pick a frontend and optionally a version, otherwise I guess it could be ported to Elixir by reusing what is done for the emoji packs.

I'm all for making this aspect more modular, but we should still ship fallback artifacts for the frontends in our releases, so that they are actually complete. The install process can still offer to install them or not, but I wouldn't want the install process to require downloading additional artifacts from the net. The usual criticism for 'blobs' (proprietary, impossible to check, impossible to replace) don't really apply to our case.

I'm all for making this aspect more modular, but we should still ship fallback artifacts for the frontends in our releases, so that they are actually complete. The install process can still offer to install them or not, but I wouldn't want the install process to require downloading additional artifacts from the net. The usual criticism for 'blobs' (proprietary, impossible to check, impossible to replace) don't really apply to our case.

We also still need to have some way to indicate what frontend version is meant to be used with the current state of the backend, but we could do that with a text file that lists the git hashes of the 'verified' frontends. The release building process could then use those hashes to prefetch the correct artifacts.

We also still need to have some way to indicate what frontend version is meant to be used with the current state of the backend, but we could do that with a text file that lists the git hashes of the 'verified' frontends. The release building process could then use those hashes to prefetch the correct artifacts.

Worked on in #5778

Worked on in #5778
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma#1285
No description provided.