Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get the project to a runnable state #1

Merged
merged 3 commits into from
Apr 11, 2021
Merged

Get the project to a runnable state #1

merged 3 commits into from
Apr 11, 2021

Conversation

StuartMacKay
Copy link
Contributor

If you try and run the project with python manage.py runserver then Django starts complaining about setting the SECRET_KEY, etc.. The reason is that it's picking up the settings/init.py which is empty.

Since all the settings files are identical, the settings directory was remove to allow the runserver command to function.

Git's ignore file was also updated to ignore any virtual environment created locally along with any dot-files which might be created by the likes of PyCharm.

@YPCrumble
Copy link
Owner

@StuartMacKay the only issue is that I believe this will break the Molecule tests because Ansible Django Stack relies on settings.production no? Maybe better is to use the new:

from django.core.management.utils import get_random_secret_key
SECRET_KEY = get_random_secret_key()

...but I'm not sure whether that's the only fix required.

@StuartMacKay
Copy link
Contributor Author

This commit is part of a package of 3. I needed the site to work so I could add the config files for celery #2 and be sure that I could start a worker. The final PR is jcalazan/ansible-django-stack#177.

I tested 177 before I submitted all three PRs so I know the molecule tests pass.

I checked that all 4 settings files were identical before I took the decision to delete the settings dir and use the settings.py in the same directory as urls.py, wsgi.py, etc.

Strictly speaking this PR is not absolutely required since I know #2 works but it would be nice to have a runnable project all the same. if you want to keep the prod settings then that's fine with me.

@YPCrumble
Copy link
Owner

@StuartMacKay this is the line that I'm pretty sure will fail - because it expects a settings folder: https://github.com/jcalazan/ansible-django-stack/blob/29beccfaffb01289be8825ca4235c22bdd1efc14/env_vars/vagrant.yml#L42

There's a similar line in env_vars/development.yml.

I agree that we should probably make this default project repo as close to the automated output of createproject - I may find time to update soon but if you do first please go ahead!

This reverts the previous commit where the settings directory was removed
as the three settings files in it (local.py, development.py and production.py)
were identical to settings.py in the parent directory.

The files in the settings directory are used in ansible-django-stack however
when this change was tested only the play recap was reviewed which reported
that all the tests passed. In fact the steps which performed django related
tasks had in fact failed. This was only revealed when running the tests with
ansible in debug mode.
This is the settings which should have been removed, not the settings
module. See the previous commit message for why.
@StuartMacKay
Copy link
Contributor Author

StuartMacKay commented Apr 11, 2021

I checked this over and the task Run Django database migrations does fail. My mistake was only to look at the last task thinking that was the overall playbook status. Instead each task needs to be reviewed for errors. Even then it's best to run molecule in debug mode since you're more likely to see the failed task output if your terminal colorizes the output.

The latest update removes settings.py in the project's root directory instead. This file is definitely not used in the ansible-django-stack playbook and it's an exact copy of the files in the settings module.

UPDATE: When there are failed tasks the molecule tests don't reach the idempotence, side_effect or verify actions. However to make matters "worse" the Delete docker network(s) is always run last so you have to be extra vigilant and check the all of the output for any indication of failures.

@YPCrumble YPCrumble merged commit 5f572c1 into YPCrumble:main Apr 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants