Preliminary tests show that it's possible to zip the ./persistence folder once installed,
transfer it to another machine and run it as is.
It should be possible to compile an installation on CI, and propose it as a local dev env release, allowing for a much faster time to first run, with less filesystem manipulations and compilation problems.

The local install process could then be mainly downloads, and split in 2 categories:

• Local dev for NRO developers:
  • don't need the main repos to be ready to edit
  • we can just download the compiled persistence folder and run on it right away
• Local dev for main repos developers:
  • still need main repos installed for edition (git repo, npm dev dependencies, etc.)
  • we can still download the release, which will avoid all the wordpress installation process
  • then we replace the required repos with live ones, running the known repos/update targets

=make from-release=

• download latest release file if not exists
• unzip file to ./persistence
• =make run=
  Builds/run all containers, taking persistence folder as a pre-built wordpress install
• =make config=
  Config needs to be set, it didn't necessarily run before, and it should follow local config
• NRO devs can then run =make nro-enable=

=make dev-from-release=

• =make from-release=
• =make repos=
• =make deps=

Tests described in https://jira.greenpeace.org/browse/PLANET-5976 would then need to be changed to:

• Install from scratch (the current =make dev=)
• Basic checks, NRO checks
• Create release
• Install from release
• Basic checks, NRO checks
• Publish release

The problems to solve:

• files ownership might be off after unzip
• because wordpress install never ran on the php container, some fixes on permissions settings for /app and composer also never ran, see https://github.com/greenpeace/planet4-docker/blob/main/src/planet-4-151612/wordpress/etc/my_init.d/20_install_wordpress.sh , we should move those to always run or if some check fails