Out of curiosity, can I ask the reason of making these volumes shareable?

Other than that, as far as I understand. :thumbsup:

The file is shared with the dev container (which mounts the whole repo clone containing this file).

Consider using /bin/bash on line # 15, because [[ is BASH feature. The /bin/sh typically points to bash and it's even possible for BASH to react on whether it was invoked through sh or bash command, but it works in some environments and/or it's possibly depending on bash version/OS distro. I am not sure here.

To avoid problems, I'd rather be safe about using the feature(s) with the appropriate shell.

OK, got it, thanks. I forgot to change the shell after adding this check. I'm changing it also below (just to be safe).

Rebased, resolved conflicts and removed -k/--insecure flag when fetching certificate.

@lholecek I'd suggest changing of names of services to distinguish between them, as a part of this PR, to make it a bit more clear.

wdb -> waiverdb-db
rdb -> resultsdb-db
gmemcached -> memcached (or why the "g"?)
waiverdb -> waiverdb-service
resultsdb -> resultsdb-service
dev ... keep "as is"

What do you think?

@lholecek I'd suggest changing of names of services to distinguish between them, as a part of this PR, to make it a bit more clear.
wdb -> waiverdb-db
rdb -> resultsdb-db

OK.

gmemcached -> memcached (or why the "g"?)

OK (not sure why the "g" - thought it may be GNU :) - it was like that before and I didn't change the service names).

waiverdb -> waiverdb-service
resultsdb -> resultsdb-service

I like the simpler names better (these could be useful for testing, e.g. docker-compose exec dev curl http://resultsdb:5001/api/v2.0/results). But I'll rename the database services.

Follow up to fix tests in #426.

This file seems missing.

Same as above.

DTTO

DTTO

MMm doesn't work for me:

~/proj/greenwave (pr416)$ sudo !!
sudo docker-compose up -d
greenwave_waiverdb-db_1 is up-to-date
greenwave_memcached_1 is up-to-date
greenwave_resultsdb-db_1 is up-to-date
Starting greenwave_waiverdb_1 ... 
Starting greenwave_waiverdb_1 ... done
Creating greenwave_dev_1      ... done
~/proj/greenwave (pr416)$ sudo docker-compose exec dev pip3 install --user -r dev-requirements.txt
ERROR: No container found for dev_1

Could you check?

@gnaponie Any errors in docker-compose logs dev? Maybe docker-compose up --force-recreate could help.

@lholecek does that help? https://paste.fedoraproject.org/paste/1y09emE0sMHy~-0-LTUzHw

You have to set DEV_USER_ID=$UID (or whatever the owner of docker/home is):

echo DEV_USER_ID=$UID >> .env

The default is 1000, that should work for everyone! :)

Works for me! Looks good to me!

I still get an error...
Any idea?
https://paste.fedoraproject.org/paste/XjeRaPdYLblFyUaccrKNqg

ImportError while loading conftest '/code/conftest.py'.
py._path.local.LocalPath.ImportMismatchError: ('conftest', '/home/gnaponie/proj/greenwave/conftest.py', local('/code/conftest.py'))

@gnaponie Yeah, this is Python interpreter cluttering the working directory with *.pyc files and not updating them when needed. :/

To fix it, run:

find -name '*.pyc' -delete

I get 11 errors running the tests... could you check?
https://paste.fedoraproject.org/paste/FKtsSCOZH--Fr4GUPo30Fw

I think you just might need to rebase on master.

Rebased, tests seem to work.

Can we put:
docker-compose up -d --force-recreate
here?

Why this part was removed?
That was really useful and requested by stakeholders.

Can we put:
docker-compose up -d --force-recreate
here?

Added a note to the docs. I'm using the flag occasionally, but not entirely sure how it's different from docker-compose build.

Why this part was removed?
That was really useful and requested by stakeholders.

Do you mean cp conf/settings.py.example conf/settings.py? (Sorry, I can no longer see the line you were commenting on.)

I think docker-compose uses only docker/greenwave-settings.py. It could be definitely useful to be able to override the configuration but I'm not sure how (maybe an optional import?).

Do you mean cp conf/settings.py.example conf/settings.py? (Sorry, I can no longer see the line you were commenting on.)
I think docker-compose uses only docker/greenwave-settings.py. It could be definitely useful to be able to override the configuration but I'm not sure how (maybe an optional import?).

No, I was talking about the "Run the development server:" part.

No, I was talking about the "Run the development server:" part.

It's part of docs/dev-guide.rst. I don't see reason to mention it in docker-compose context.

Can we put:
docker-compose up -d --force-recreate
here?

Added a note to the docs. I'm using the flag occasionally, but not entirely sure how it's different from docker-compose build.

It's like docker-compose down && docker-compose up

This PR looks fine. Let's merge it.

Commit f62e42f3 fixes this pull-request