You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
Wamm K. D d391c75613 I think this was alignment to something which no longer is there to 6 days ago
assets Also, limit the height of the video. 7 days ago
config So, apparently, the scope of the service worker gets defined from 2 weeks ago
lib I think this was alignment to something which no longer is there to 6 days ago
priv Those in place, let's add =Video=s to the mix. 1 week ago
rel/overlays/bin Fly.io generated a =Dockerfile= for me, based off of ~mix 2 weeks ago
test Also, the tests; 'makes me wonder if I ever generated the files for 1 year ago
.dockerignore Fly.io generated a =Dockerfile= for me, based off of ~mix 2 weeks ago
.formatter.exs And the start of a new Phoenix project. 2 years ago
.gitignore Another new change: truly static files go under `/priv/static/`, now, 2 months ago
CODE_OF_CONDUCT.md This is…wildly subjective and ablist to autistic people, who have 1 year ago
Dockerfile Fly.io generated a =Dockerfile= for me, based off of ~mix 2 weeks ago
LICENSE Initial commit 4 years ago
Procfile Adding these to (hopefully) be able to deploy to Heroku. 2 years ago
README.org Grabbing this as an environment variable is already in the code but 2 weeks ago
ROADMAP.org Also, a note for myself… 2 weeks ago
compile Speaking of defaults for the buildpacks, let's tweak the default to 2 months ago
elixir_buildpack.config And, while we're on it, update these versions so they reflect what I'm 2 months ago
fly.toml Fly.io generated a =Dockerfile= for me, based off of ~mix 2 weeks ago
mix.exs I'm not sure how useful some of these aliases are; they're mostly 2 months ago
mix.lock And that should be the last change for the lock. 2 months ago
package-lock.json And, with those changes in place, we can update the package-lock. 2 months ago
phoenix_static_buildpack.config O. K.; so I don't remember if the root of the project had 2 years ago

README.org

Swanye

A tumblelog in the style of Tumblr.

Swanye is still incredibly pre-alpha software; it is highly unrecommended to run Swanye in anything other than a local setup, at this point in time.

Getting started

Swanye relies on a few dependencies:

In order to run Swanye, make sure you have these installed; basic, out-of-the-box configuration should suffice to get Swanye working. Do remember to create a user for the username and password defined under config/dev.exs.

With those installed, – to start your Phoenix server –:

  • Install dependencies with mix deps.get
  • Create and migrate your database with mix ecto.setup
  • Install Node.js dependencies with npm install inside the assets directory

    • this is primarily to run the SASS monitor when developing which will build the CSS files we need for production
    • JavaScript will be handled by Phoenix's esbuild
  • Start Phoenix endpoint with mix phx.server

Now you can visit localhost:4000">localhost:4000 from your browser.

Ready to run in production? Please check Phoenix's deployment guides.

Production Deployment

Currently, I've been deploying this code via Heroku. I've been using the buildpacks Heroku Buildpack Elixir and Phoenix Static Buildpack.

The relevant files for the first buildpack are Procfile and elixir_buildpack.config. Procfile sets which environment is being used and holds the command to start the project. elixir_buildpack.config's most relevant bits are setting the versions of both Erlang and Elixir.

The relevant files for the second buildpack is compile, overwriting the default compile script of Phoenix Static Buildpack. The main difference from the default script is using mix "assets.deploy" instead of mix "${phoenix_ex}.digest".

The SASS and JavaScript files under assets (in /css and /js, respectively) need to be generated so the processes handled by the files, above, need to be ensured if you try to run this code outside of a Heroku (with the aforementioned buildpacks) environment/situation.

Environment Variables

While MariaDB variables are already hardcoded so that the don't need to be provided to connect to a database when running locally, the variables MAILGUN_API_KEY and MAILGUN_DOMAIN must be provided for E-mail functionality. Currently, Swanye is setup to use Mailgun to send E-mails; obviously, providing greater choice (and, hopefully, more libre options) is a desire, for the future.

DREAM_OBJECTS_ACCESS_KEY_ID and DREAM_OBJECTS_SECRET_ACCESS_KEY can be provided to test image uploading and storage usage; you must have a DreamObjects account for this, however.

Production environment variables in use are:

  • DREAM_OBJECTS_ACCESS_KEY_ID – DreamObjects ID, for image storage
  • DREAM_OBJECTS_SECRET_ACCESS_KEY – DreamObjects Secret, for image storage
  • MARIADB_USERNAME – MariaDB username for database access
  • MARIADB_PASSWORD – MariaDB password for database access
  • MARIADB_HOST – MariaDB host/domain for database access
  • MARIADB_DATABASE – MariaDB database name for database access
  • SECRET_KEY_BASE – Used by Phoenix; generate with mix phx.gen.secret
  • MAILGUN_API_KEY – Your Mailgun-given API key
  • MAILGUN_DOMAIN – The Mailgun domain of your Mailgun account
  • PHX_HOST (for Prod.) – The domain of your site
  • PORT (optional) – The port you need your application to connect to, if not 4000

Other places to find us

If you want to follow for updates about the development progress, general updates (including my thoughts about new features and how development is going) can be found at our Mastodon account.

If you're interested in helping support me so I can work on Swanye, the project also has a Liberapay.