Refactoring plugin installation

Development

AI-generated summary

A discussion on refactoring plugin installation in Discourse began with Ori_Pekelman expressing concern over the public/plugins/ directory requiring read/write mount. They questioned the rationale behind the plugin activation part, specifically the creation, cleanup, and symlinking of the target directory. sam responded, suggesting a change to only create the symlink if it doesn’t already exist and committing /public/plugins/.gitignore to the repo. However, sam expressed hesitation in accepting a first-time PR for this change due to its complexity.

1

Hi,

I noticed that public/plugins/ requires to be on a read/write mount, which is awkward as this is code under git control..
I wanted to fix that .. but I got to the part where you install plugins .. and I find that part a bit awkward… could you please (if you remember :slight_smile: ) tell me the rationale behind the plugin activation part here:

I see you first create the target dir .. then brutally clean it up .. then symlink it..
In the commit messages, I see something about not breaking Jenkins … (so possibly the rationale is stale..).

I’d be happy to try and have a stab at this… (and generally going over the whole thing making sure nothing under git control is on R/W mounts).

2

I think I am fine for changing it so it only does the ln if for some reason the symlink does not already exist.

Also open to committing /public/plugins/.gitignore into the repo so the folder is always there and then we can get rid of the mkdir.

This is a very very fiddly change though I am not super comfortable accepting a first time PR for it.