README.md: full rewrite for pleroma

This commit is contained in:
Morgan Bazalgette 2018-03-29 01:46:07 +02:00 committed by Haelwenn (lanodan) Monnier
parent 1a151397e5
commit 38ca2a8425
No known key found for this signature in database
GPG key ID: D5B7A8E43C997DEE

View file

@ -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 theyll 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 isnt 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 dont have yarn)
- Launching the frontend is done with `npm run dev`. It should be reachable once it finnishes compiling.