First off, thank you so much for taking the time to contribute to this project. With help from people like you around the world we make Cambiatus what it is.
Following these guidelines while contributing helps us ensure that we can find better and more efficient ways of working together. This in turn helps the whole community collaborate better and achiever higher heights in its endavours.
Our team at Cambiatus loves receiving contributions from the community, It is indeed contributors like you that have enabled us and continue to enable us to build the tools we build. There are many ways of contributing to the Cambiatus Backend you could help with commnunity management, writing manuals, teaching, submitting bug reports and feature request or even writing code that get used by the entire Cambiatus community.
Please don't use Github Issues to get support questions. Check whether the #devs channel on the Cambiatus Open Source Discord Servers can help you get your question answered.
First of all take a deep breath and relax, everyone started exactly where you are.
- Unsure where to begin contributing to the Cambiatus backend? You can start by looking through issues tagged with
good-first-issuethese are issues that involve easy tasks that whet your appetite for more and show you around. Help wanted issues- these are issues that may be a little more involved for a beginner but ultimately also a good foray into the codebase.
Working on your first Open Source contribution? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
- Fork the repo, this enables you to open PRs and push them.
- Work the setup guide
- Run the test suite MIX_ENV=test mix test. Please note we only accept pull requests with passing tests, and it's awesome to make one pass. Small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a patch, without forking the repo. If you find a security vulnerability, do NOT open an issue. Inform the #devs on the discord channel.
Bug reports can be filed using the issue template on this projects github repository, This format enables us to respond quicker and clearly to any bug reports.
- What version of the backend are you using (mix: version)?
- What did you do?
- What did you expect to see?
- What did you see instead?
Many of the features that this backend has today have been added because our users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work. We tend to prefer that our feature request and enhancements start as issues, formatted this way they make it very clear to the whole community what the aim of the request is and how it will change the work.
The core team looks at Pull Requests on a regular basis in a weekly triage meeting that we hold. The meeting is announced in the weekly status updates that are send on Monday mornings. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.
You can chat with the core team on the discord channel linked above. We try to be available on all weekdays.
Oh wow! you are grown now, you even have your very own deployment keys how do you get this to work in the wild? Well follow the guide below and you should be having lots of fun soon!
We use distillery and docker as our preferred tools for deployment. and you can bootstrap on this to get a self contained running version easily as follows:
- You can build a docker image of the version you want by running
make buildin the project's root folder this invokes a make file that builds a constainer image of a release. - You can then run
make pushto upload this image to a registry, if using a different registry rather than the cambiatus one you may need to modify the make file with your own details - Ensure to have docker authenticated as your work through this
Once built and now you intend to run it on a server you can run the following commands
~/cambiatus/cambiatus/bin/cambiatus remote_consoleto attach to the running process~/cambiatus/cambiatus/bin/cambiatus foregroundto run it and keep the output locked to the current session~/cambiatus/cambiatus/bin/cambiatus startto start it on the background~/cambiatus/cambiatus/bin/cambiatus consolefor a IEx session
To run migrations you can run:
~/cambiatus/cambiatus/bin/cambiatus migrateFor running migrations~/cambiatus/cambiatus/bin/cambiatus seedFor adding seeding- Note these are now run automatically when starting a release
docker build -t 'cambiatus/backend:latest' .
The default env will be development, if you want to build it for prod:
docker build -t 'cambiatus/backend:latest' --build-arg "MIX_ENV=prod" .
docker run -t 'cambiatus/backend:latest'
If you are running in prod env you'll also need to set the database env variables:
docker run -e "DB_HOST=example.host" -e "DB_PORT=5432" -e "DB_USER=user" -e "DB_PASSWORD=123" -e "BESPIRAL_WALLET_PASSWORD=kw123" -t 'cambiatus/backend:latest'
# OR
docker run --env-file=env_file_path -t 'cambiatus/backend:latest'If you are using docker-compose:
version: '3'
services:
x:
image: 'someimage:latest'
env_file: env_file_path
-- or
environment:
- BESPIRAL_WALLET_PASSWORD=123
- DB_HOST=example.host
- DB_PORT=5432
- DB_USER=user