README.md: full rewrite for pleroma

README.md

@@ -1,12 +1,72 @@
-#  Mastodon Glitch Edition  #
+# Mastodon Frontend, Glitch-soc + Pleroma Edition
 
->   Now with automated deploys!
+Here is a distribution of the glitch-soc frontend for pleroma. Everything from the upstream repository is kept and rebased on for easy updates, this does screws up on Merge Requests so they’ll be treated as a patchset if done here.
 
-[![Build Status](https://img.shields.io/circleci/project/github/glitch-soc/mastodon.svg)][circleci]
+# Fork vs. Distribution
+This repository is not a fork of glitch-soc, there is only a few patches on it that are kept and designed to be easily removable if it needs to (for example when upstream does one of our features on their side too).
+This also means that there is no merge, only one big rebase to get the patches up-to-date. See the Development section for more information.
 
-[circleci]: https://circleci.com/gh/glitch-soc/mastodon
+# Deployement
+## Fetching CI artifacts
+Pleroma (backend) has a shell script in `installation/download-mastofe-build.sh` which can be used to get a build from the CI artifacts, by default it will install the one from `rebase/glitch-soc` into `instance/static` (so you can revert to the bundled frontend by removing it and it is free from git conflicts), this behaviour can be changed by modifying the first lines of the script.
 
-So here's the deal: we all work on this code, and then it runs on dev.glitch.social and anyone who uses that does so absolutely at their own risk. can you dig it?
+## Updating the bundle
+This is what you want to do to update the mastofe bundled with pleroma.
 
-- You can view documentation for this project at [glitch-soc.github.io/docs/](https://glitch-soc.github.io/docs/).
+- Run ``build.sh`` at the root of this repo, you can set the ``TARGET`` environment variable if pleroma isn’t at ``../pleroma`` (default value of ``TARGET``)
-- And contributing guidelines are available [here](CONTRIBUTING.md) and [here](https://glitch-soc.github.io/docs/contributing/).
+- Go to pleroma repo:
+  - ``git add priv/static/sw.js priv/static/packs``
+  - ``git commit -m "update mastofe"``
+
+# Development
+## Branches
+- `pleroma` branch which get re-referenced to `rebase/glitch-soc` once it is stable
+- `master`: Same branch as upstream repository, should be updated before doing an updating rebase
+- `rebase/glitch-soc`: branch which rebases from upstream, used for testing
+
+For developement/Merge Requests I would suggest to use `master` when you are introducing new modifications that cannot be in the upstream, and when you are changing current modifications prefer `rebase/glitch-soc`.
+
+Never use `pleroma` as a base for Merge Requests, it is not meant to be modified directly.
+
+## Changelog
+There is a `Changelog-mastofe.txt` file used to do the release notes for the message on tagging a new release. It is cleaned when updating from upstream (`git filter-branch` should be a nice friend).
+Changes on the behaviour of the frontend should be noted in this file together with their modification (commit at best, MR at worst).
+
+## Tools
+- Node.js
+- yarn (preferred) or npm
+- HTTP proxy (such as nginx)
+
+## nginx setup
+I'll assume that you have already fired up pleroma using the installation guide. To work on the frontend while still having the backend up, use this nginx config.
+
+```
+server {
+    listen 80;
+    server_name pleroma.testing;
+
+    location /packs {
+        add_header 'Access-Control-Allow-Origin' '*';
+        proxy_http_version 1.1;
+        proxy_set_header Host $http_host;
+
+        proxy_pass http://localhost:3035;
+    }
+
+    location / {
+        add_header 'Access-Control-Allow-Origin' '*';
+        proxy_http_version 1.1;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Connection "upgrade";
+        proxy_set_header Host $http_host;
+
+        proxy_pass http://localhost:4000;
+    }
+}
+```
+
+Change the `server_name` if you like. I personally like to create a new entry in /etc/hosts and add `127.0.0.1 pleroma.testing`, but you do what suits you.
+
+## Running
+- Getting the node dependencies is done with `yarn install -D` (or `npm install` if you don’t have yarn)
+- Launching the frontend is done with `npm run dev`. It should be reachable once it finnishes compiling.