If you have any questions please reach out to us via slack: yunity slack and join the #foodsharing-dev channel.
Submitting an issue
If you found an issue on the foodsharing website, then please submit it to our GitLab issues.
If you feel comfortable submitting a fix (or if you like to try ;) ) too, then follow the next section.
Submitting a change
Becoming a member
As an “member” on Gitlab you can
- create and push to branches within the repository (except master)
- see confidential issues
- set labels to issues
- assign yourself to issues (to tell others that they do not need to start on them) After creating a Gitlab account and applying for membership, write a few introducing lines about you on the Slack channel yunity slack #foodsharing-dev. You can apply for membership by clicking the Request Access Button in the GitLab UI, after you created your account.
Working on an issue
You can either submit your own issue and work on it or work on existing issues. Issues that are suitable for newcomers are labeled as starter tasks.
To work on an issue:
- Check if there is an issue for the change in the GitLab issues.
- This is a seperate project as it is public and the repo is not.
- If you are just submitting a very small change or a doc fix, then don't worry about creating an issue.
- Create a new git branch, prefixed with the issue number rather than fork the repo, as it makes permissions trickier.
- For example, the issue number
56would have a branch named
- Optionally, add your name to the branch name; for example,
- For example, the issue number
- Make your changes and push them. If they are very small or only documentation you can consider using the push option
git push -o ci.skipwhich disables running the build and test on the Gitlab server.
To submit your change:
- Check if the code style is fixed before commiting, by running
./scripts/fix-codestyle-local(or if that does not work by running the slower
- Check if the tests pass locally, by running
- Create a merge request to master for your branch early on.
- Select the template "Default".
- Prefix the name of the merge request with
- Make sure your merge request checks all the checkboxes in the "Default" template (and check them in the description).
- Once you think your branch is ready to be merged, remove the
WIP:prefix from the name of your merge request. Rebase your branch onto master (which might have developed since your branching). It is OK to force-push (
git push origin <your_branch_name> -f) after rebasing.
- Submit your merge request.
The next steps will be:
- An approver will get back to you with feedback or change requests. Please have some patience if this does not happen right away.
- Once the approver considers your changeset ready to be made, they will merge it into the master branch.
- The master branch will be deployed automatically to beta.foodsharing.de, where you can try it out (uses production database).
- See environments on GitLab for an overview of the different environments.
- Hang around and see if people in #foodsharing-beta on Slack find any issues, etc.
- At some point in the future, once a few changes have been collected, they will all be deployed to production.
You can run the tests with
for your second and following runs, you can use
./scripts/test-rerun which runs much quicker
(as long as we keep writing the tests to run idempotently, please do!).
So far, end to end tests (called acceptance tests in codeception) work nicely. They run with a headless Firefox and Selenium inside the Docker setup and they are run on CI build too.
We are restructuring the code to enable unit testing.
Related issue: Incremental refactor.
If you want to run the tests with debug mode turned on, use:
If you just want to run one test, pass the path to that test as an argument,