From 38ca2a8425d5db664095b881b6ea26433d4db32e Mon Sep 17 00:00:00 2001 From: Morgan Bazalgette Date: Thu, 29 Mar 2018 01:46:07 +0200 Subject: [PATCH] README.md: full rewrite for pleroma --- README.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 67 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 470e379dc..16601eddd 100644 --- a/README.md +++ b/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/). -- And contributing guidelines are available [here](CONTRIBUTING.md) and [here](https://glitch-soc.github.io/docs/contributing/). +- 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``) +- 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.