1620b35045
Bugfix: build.sh: use TARGET env variable and check it See merge request pleroma/mastofe!17 |
||
---|---|---|
.circleci | ||
.github | ||
app | ||
bin | ||
config | ||
db | ||
dist | ||
lib | ||
log | ||
nanobox | ||
public | ||
spec | ||
streaming | ||
vendor | ||
.buildpacks | ||
.codeclimate.yml | ||
.dockerignore | ||
.editorconfig | ||
.env.nanobox | ||
.env.production.sample | ||
.env.test | ||
.env.vagrant | ||
.eslintignore | ||
.eslintrc.js | ||
.foreman | ||
.gitattributes | ||
.gitignore | ||
.gitlab-ci.yml | ||
.gitmodules | ||
.haml-lint.yml | ||
.nanoignore | ||
.nvmrc | ||
.profile | ||
.rspec | ||
.rubocop.yml | ||
.ruby-version | ||
.scss-lint.yml | ||
.slugignore | ||
.yarnclean | ||
app.json | ||
Aptfile | ||
AUTHORS.md | ||
babel.config.js | ||
boxfile.yml | ||
build.sh | ||
Capfile | ||
CHANGELOG.md | ||
CODE_OF_CONDUCT.md | ||
config.ru | ||
CONTRIBUTING.md | ||
docker-compose.yml | ||
Dockerfile | ||
Gemfile | ||
Gemfile.lock | ||
jest.config.js | ||
LICENSE | ||
package.json | ||
postcss.config.js | ||
priv-config | ||
Procfile | ||
Procfile.dev | ||
Rakefile | ||
README.md | ||
scalingo.json | ||
Vagrantfile | ||
yarn.lock |
Mastodon Frontend, Glitch-soc + Pleroma Edition
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.
Deployement
This is what you want to do to update the mastofe bundled with pleroma.
- Run
build.sh
at the root of this repo, you can set theTARGET
environment variable if pleroma isn’t at../pleroma
(default value ofTARGET
) - Go to pleroma repo:
git add priv/static/sw.js priv/static/packs
git commit -m "update mastofe"
Development
Branches
pleroma
branch which merges fromrebase/glitch-soc
once it is stablemaster
: Same branch as upstream repositoryrebase/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.
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
(ornpm install
if you don’t have yarn) - Launching the frontend is done with
npm run dev
. It should be reachable once it finnishes compiling.