- Mention the need for Redis if Celery is selected
- Link to PostgreSQL & Redis download pages
- Detail better how to set the environment
- Improve internal links using Sphinx' :ref
- Remove unused link
* Add note about using keep_local_envs_in_vcs
As a newbie, I wasn't sure about `keep_local_envs_in_vcs`, so I said yes, and when CC was building, it gave me the message:
"[INFO]: .env(s) are only utilized when Docker Compose and/or Heroku support is enabled so keeping them does not make sense given your current setup."
Seems like it could go in this documentation, and make things easier for newbies.
* Add me to CONTRIBUTORS.RST
* Integrate Flower with Docker Compose setup locally
* Remove alien worker celeryd option
* Move Flower COPY section below the worker's
* Remove set -o pipefail command from Flower start script
* Flower client authentication
* Override flower service image name
* Move flower service to the end of local.yml
* Install flower==0.9.2 in all environments
* Introduce production flower service
* Fix local flower start script
* Document Flower integration
* Prettify *.django envs
Rationale: consistency.
* Reference local environment Flower docs from the production's
* 'two more services' -> 'three more services'
* Export PG* envs when backing up postgres
* Export PG* envs when restoring postgres from backup
* Prevent postgres connection from dropping all at ones
* Alter postgres backups docs
Include another crucial prerequisite.
* "feel free switching" -> "feel free to switch"
* Address the feedback
* Update generated project's .gitignore
* Post-gen gitignore .env/ and .env
* Fix linesep between gitignored entries
* Persist `.env/**/*` files into cookiecutter-django's VCS
* Rename .env/ to .envs/
* Reference the newly created .envs/**/.* files in local.yml
* Reference the newly created .envs/**/.* files in production.yml
* Delete .env.example
* Refactor post-gen-project.py
Closes#1299.
* Implement production-dotenv-files-to-dotenv-file merge script
* Create shared PyCharm Run Configuration for the automation script
* Randomize POSTGRES_PASSWORD in ./envs/(.local|.production)/.postgres
* Default POSTGRES_PASSWORD and POSTGRES_USER to random values
* Fix jinja linebreaks in local.yml
* Spaces in production.yml
* Fix post-merge leftovers & set DJANGO_ADMIN_URL automatically
* Prettify here and there
* Fix FileNotFoundError
* Leave a TODO in post_gen_hook.py
* Introduce keep_local_envs_in_vcs option
* Remove envs when not opted for
* Inline pre_gen_project.py if-condition
* Get rid of PROJECT_DIR_PATH in post_gen_project.py
* Clean up the docs
* Match copyright notices
* Document envs ins and outs
When creating a Mailgun add-on on Heroku, the app gets some environment
variables by default:
MAILGUN_API_KEY
MAILGUN_DOMAIN
However, the cookiecutter names do not match and requires a manual step
from the user deploying. It's used elsewhere but shouldn't harm the
other deployment methods to rename these variables.
While updating the docs I noticed a variable that appear unused
DJANGO_MAILGUN_SERVER_NAME so this removes it from the documentation.
* Fix ./hooks/pre_gen_project.py asking user to select an option once only
+ prettify output
* Fix pre_gen hook not really exiting when it should
* Refactor & prettify ./hooks/post_gen_project.py
* Ensure same POSTGRES_USER is set across environments
+ get rid of env.example in favor of pre-generated .env.
* Add Bootstrap to package.json in case of custom_bootstrap_compilation
* Update JS task runners and base HTML to handle custom scss compilation
* Generate a vendors.js with custom bootstrap compilation + Gulp
* Update documentation accordingly
* Add missing if/endif in gulpfile
* Update to Bootstrap v4 final
* Introduce static asset build infrastructure
* Enhance gulpfile.js
* Introduce node service
* BrowserSync debug-only support
* Remove newline before BrowserSync debug-only support section
* FIx node Dockerfile package.json COPY
* Try fiixing node Dockerfile package.json COPY ones again
* Switch to `node:7-slim`
* Try switching to node:6
To account for possible node:7 docker-compose incompatibiltiy
* Revert "Try switching to node:6"
This reverts commit 62cc02df1a.
* Try switcging workdir to /app
* Try utilizing relative package.json path
* Resetting to the last version working locally with docker-compose 1.11.x
* Build upon the latest node:7.9-slim
* Stop dockerignoring package.json
* Fix typo
* Try a different package.json path
* Revert "Try a different package.json path"
This reverts commit f29f8500b8.
* Revert "Fix typo"
This reverts commit 02033729b5.
* Revert "Stop dockerignoring package.json"
This reverts commit 63c5491546.
* Upgrade docker-engine and docker-compose used by Travis CI
* Fix .travis.yml comments
* Inline docker-engine and docker-compose versions
* DEBUG: pwd
* Revert "DEBUG: pwd "
This reverts commit 6c2ed4321a.
* Try copying package.json to the same dir as node Dockerfile's
* Revert "Try copying package.json to the same dir as node Dockerfile's"
This reverts commit 24340a0783.
* Try out node:7.9
* Revert "Try out node:7.9"
This reverts commit 32286d33c2.
* Revert "Upgrade docker-engine and docker-compose used by Travis CI"
* Get rid of npm-check-updates
Reason: Reserved for the upcoming PR
* Get rid of npm-check
Reason: Reserved for the upcoming PR
* Get rid of 'standard' npm package
Reason: Reserved for the upcoming PR
* Clean up package.json
* Preserve package.json uncoditionally
Since we now have *unconditional* node.js integration, `package.json` must be out there whenever `node` service gets built
* Upgrade node service image to 7.10
* Document Node.js-Docker integration
* Fix gulpfile.js images region name
* Get rid of Gulp migrate task
* Document Gulp-Docker integration
* Introduce static asset build infrastructure
* Enhance gulpfile.js
* Introduce node service
* BrowserSync debug-only support
* Remove newline before BrowserSync debug-only support section
* FIx node Dockerfile package.json COPY
* Try fiixing node Dockerfile package.json COPY ones again
* Switch to `node:7-slim`
* Try switching to node:6
To account for possible node:7 docker-compose incompatibiltiy
* Revert "Try switching to node:6"
This reverts commit 62cc02df1a.
* Try switcging workdir to /app
* Try utilizing relative package.json path
* Resetting to the last version working locally with docker-compose 1.11.x
* Build upon the latest node:7.9-slim
* Stop dockerignoring package.json
* Revert "Stop dockerignoring package.json"
This reverts commit 63c5491546.
* Fix typo
* Revert "Fix typo"
This reverts commit 02033729b5.
* Try a different package.json path
* Revert "Try a different package.json path"
This reverts commit f29f8500b8.
* Upgrade docker-engine and docker-compose used by Travis CI
* Fix .travis.yml comments
* Inline docker-engine and docker-compose versions
* DEBUG: pwd
* Revert "DEBUG: pwd "
This reverts commit 6c2ed4321a.
* Try copying package.json to the same dir as node Dockerfile's
* Revert "Try copying package.json to the same dir as node Dockerfile's"
This reverts commit 24340a0783.
* Try out node:7.9
* Revert "Try out node:7.9"
This reverts commit 32286d33c2.
* Revert "Upgrade docker-engine and docker-compose used by Travis CI"
* Get rid of npm-check-updates
Reason: Reserved for the upcoming PR
* Get rid of npm-check
Reason: Reserved for the upcoming PR
* Get rid of 'standard' npm package
Reason: Reserved for the upcoming PR
* Clean up package.json
* Preserve package.json uncoditionally
Since we now have *unconditional* node.js integration, `package.json` must be out there whenever `node` service gets built
* Upgrade node service image to 7.10
* Document Node.js-Docker integration
* Fix gulpfile.js images region name
* Get rid of Gulp migrate task
* Document Gulp-Docker integration
* Remove Gulp-Docker integraton not supported initialization message
ADDED: HTTPS is on by default. This will give a new user an
understanding of why Cookie Django is set up securely for deployment in
a production environment.
Commit 04a58d5 removed the Heroku instant deploy button but the docs
still mention this as an option, this commit updates the docs to reflect
this change.
Includes:
* First pass at Elastic Beanstalk integration
* Gets code and elasticache working
* Very rudimentary documentation
* Includes post hook cleanup
Removed sections about using Docker Toolbox with virtualbox and added links to Docker for Mac/Windows.
Docker for Mac/Windows uses native virtual machines instead of virtualbox and introduces many improvements.
See: https://blog.docker.com/2016/03/docker-for-mac-windows-beta/Resolves: #706
* Remove webpack and merge
* Put postgresql_version line back in cookiecutter.json
* Put goldhand back in contributors file, added ssteinerX
* Add *.egginfo to .gitignore
* Fix dangling endif in README.rst
In order to resolve the name through docker's dns, we have to specify
the usual container name (certbot) - docker-compose only does
automatically this if you use `start certbot`, not with `run`.
Also added --rm to remove the container after it's done so we don't have
multiple with the same name
* Add webpack as an option
Adds webpack as a js_taskrunner option to cookiecutter-json. Will clone @hzdg/cookiecutter-webpack --pydanny-django branch into the project using cookiecutter's api in post_hooks.
The static webpack project will be placed into the <project_slug>/static/<project_slug>/ directory.
The webpack configs are placed in the ./config/ directory.
The cookiecutter-webpack project includes react / redux / karma configurations that are brought into the project.
* Add webpack documentation
As somebody new to mailhog, I was a confused on how to use it. I first assumed, it was going to be used by the django app itself. After reading more on the internet I found it needed to be executed outside of the django application.
The app name wasn't displayed correctly on the new relic dashboard.
Although `NEW_RELIC_APP_NAME` was set in `production.py`, the variable was not loaded *before* the newrelic agent was called.
Since the new relic agent is loaded at a very low level, NEW_RELIC_APP_NAME has to be set before django settings are imported.
when `heroku run python manage.py check --deploy` is ran this error occurs
?: (security.W009) Your SECRET_KEY has less than 50 characters or less than 5 unique characters. Please generate a long and random SECRET_KEY, otherwise many of Django's security-critical features will be vulnerable to attack.
changing the num of ran to a larger number fixes this issue
