- How do I interact with the app?
- How do I stop and start the server?
- How do I run tests?
- How do I rebuild Docker containers?
- How do I serve the front-end?
- Do I need special environment variables?
- How do I push changes to GitHub?
You'll generally interact with the app using docker-compose. You can choose not to if you're contributing often enough to not need to worry about dependency management. But if you're short on time, Docker is probably the happier path to get up and running quickly.
Here are conversions of your typical Elixir project commands:
iex -S mix phoenix.server→docker-compose run web iex -S mix phoenix.servermix run priv/repo/seeds.exs→docker-compose run web mix run priv/repo/seeds/.exsmix test→docker-compose run test mix test- and so on...
These follow the basic format of my-command with arguments → docker-compose run TARGET_CONTAINER my-command with arguments.
Need to stop the containers? Either Ctrl+C or in a separate prompt run docker-compose stop.
To start the services again you can run docker-compose up, or docker-compose start to start the containers in a detached state.
If you ever need to rebuild you can run docker-compose up --build. Unless you've destroyed your Docker container images, this should be faster than the first run.
To run the tests you can run docker-compose run test mix test.
Credo is a static code analysis tool for Elixir. In general, we conform to the Credo Style Guide when writing Elixir code. You can run mix credo to check your code for design, readability, and consistency against this guide.
Credo's style guide is influenced by this more popular and exhaustive community Elixir Style Guide. We defer to that guide where the Credo guide is ambiguous, e.g. external module references.
The Code Corps API is intended to work alongside a client written in Ember. For that purpose, the Elixir application exposes all of its API endpoints behind an api. subdomain.
For Ember to work with your now running API listening on localhost:49235, you simply need to run under ember serve at localhost:4200 and everything should work under normal conditions.
When contributing to the app, you will not have access to secure environment variables required to run some tests or work on aspects of the app locally. Unfortunately, for security reasons, we cannot provide you with sandboxed keys for doing this on your own.
You can see these variables in .env.example.
Without too much effort, you should be able to set up keys on your own for the following portions of the app:
If you're trying to upload and serve images like user, project, or organization icons, then we recommend you sign up for an AWS account.
In your .env you'll need the following:
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYare your credentials, typically generated from AWS IAM (identity management)CLOUDFRONT_DOMAINshould be the domain name of your CloudFront instance that sits in front of your S3 bucketS3_BUCKETshould be the bucket you'll be uploading files to
If you're testing anything with donations locally, you'll need a Stripe account.
You can register for a Stripe account here: https://dashboard.stripe.com/register
In your .env you should have a STRIPE_SECRET_KEY and STRIPE_PLATFORM_CLIENT_ID.
STRIPE_SECRET_KEYshould be set to your "Test Secret Key" from the API Keys section of your Stripe dashboard.STRIPE_PLATFORM_CLIENT_IDshould be set to "Developmentclient_id" key from the Connect section of your Stripe dashboard. You'll want to set the redirect URI tohttp://localhost:4200/oauth/stripe.
You can use git as you normally would, either on your own host machine or in Docker's web container.