Skip to content

Latest commit

 

History

History
411 lines (299 loc) · 7.62 KB

CookiecutterVariables.adoc

File metadata and controls

411 lines (299 loc) · 7.62 KB
Raw

CookieCutter variables reference

Table of Contents

How to read the variables definition

In cookiecutter.json we define all the variables used in the project.

If the value starts with _

it is not shown to the user.

If the value is an array

It limits the the value to one of the choices in the array.
The first item in the array is used as the default choice.

If the value is just a string

It is the default value. The user can change it to any input.

Values based on previous values

Values in cookiecutter.json are rendered using jinja2 templates. This means that you can use previous values in the definition of the next one.

For example:

{
    "project_title": "My Project",
    "repo_name": "{{ cookiecutter.project_title | slugify }}",
}

Adding new variables

When adding new variables to the project template cookiecutter.json make sure to also add them to CookiecutterVariables.adoc file.

Wrap them in a _ tag::my_cool_variable[] blocks, so you can automatically include the variable definition in the reference documentation.
This allows to show the default value thh documentation without having to hard-code it there.

Tip
 Don’t be afraid to add new variables, even if you’re using an existing variable in the project, just define a new variable based on the same value with a _ prefix and use it. This will allow future developers to extend the logic based on that value that use much easier.

CookieCutter variables

project_title

Public title of the project.
This is used in docs, emails navbars, etc. Anywhere the project name is shown to the public this is used.

definition
{
link:cookiecutter.json[role=include]
}

repo_name

Tip
 If you’re using repo_name or project_title in a new place in the projects where you’re using it as a string and have the ability to import django.conf.settings, import the value from there instead of using this variable, so the code is the same for all generated projects.

Preferably lowercase codename, used for the directory structure and Python modules.

Used as the root for a lot of things. Including folder names and the core project name on servers.

definition
{
link:cookiecutter.json[role=include]
}

thorgate

Are you from thorgate? Exclude common config present for Thorgate.

definition
{
link:cookiecutter.json[role=include]
}

live_domain_name

Production domain name of the site (e.g. example.com). NOTE: should be lowercase and valid FQDN.

definition
{
link:cookiecutter.json[role=include]
}

test_host

Hostname for test server. Used to generate the first ansible host.

definition
{
link:cookiecutter.json[role=include]
}

admin_email

Project email. Used for any data requiring email, django admin and certbot expiration notifications.

definition
{
link:cookiecutter.json[role=include]
}

include_celery

Include Celery with Redis as the broker.

definition
{
link:cookiecutter.json[role=include]
}

docker_base_image

Base Docker images to use.

definition
{
link:cookiecutter.json[role=include]
}

python_version

Python version to use.

definition
{
link:cookiecutter.json[role=include]
}

node_version

Node.js version to use.

definition
{
link:cookiecutter.json[role=include]
}

postgres_version

Postgres version to use.

definition
{
link:cookiecutter.json[role=include]
}

django_admin_path

Django Admin panel URL path. NOTE: Should not start or end with /.

Defaults to adminpanel.

definition
{
link:cookiecutter.json[role=include]
}

django_health_check_path

Django health check URL path. NOTE: Should not start or end with /.

Defaults to _health.

definition
{
link:cookiecutter.json[role=include]
}

django_folder_name

Directory name for the Django codebase.

definition
{
link:cookiecutter.json[role=include]
}

default_django_app

Name of the core Django app for the project

definition
{
link:cookiecutter.json[role=include]
}

django_media_engine

Django remote media storage engine to use.

definition
{
link:cookiecutter.json[role=include]
}

gitlab_repo_url

[Optional] Gitlab repo url in format: https://gitlab.com/your-group/project-name.

This is used for deriving the Gitlab repository url to use when deploying or the default Docker registry url used for the project. Additionally the CI badges in the README file are created based on this value.

Note
 If this is not defined during the project creation/upgrade then one needs to manually update the repository variable inside ansible/group_vars/all/vars.yml file of the resulting project to the correct git repository url (SSH). Additionally, when build_in_ci is set to yes then the image urls in environemnt file need to be updated to correct values too.
Warning
 If you’re using a nested group, then you should use the git@ format for the repo url. see this test case.
definition
{
link:cookiecutter.json[role=include]
}

frontend_style

Set the type of frontend to use.

definition
{
link:cookiecutter.json[role=include]
}

webapp_include_storybook

Webapp only: Include storybook configuration?

definition
{
link:cookiecutter.json[role=include]
}

x_frame_options

Set X-Frame-Options header for nginx config.

You should choose SAMEORIGIN when you want to display current page in a frame on another page, but only within the current domain.

definition
{
link:cookiecutter.json[role=include]
}

content_security_policy

This variable affects Content Security Policy (CSP) (https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) settings.

definition
{
link:cookiecutter.json[role=include]
}

use_mypy

Use MyPy static types checker?

definition
{
link:cookiecutter.json[role=include]
}

use_cypress

Use Cypress autotests?

definition
{
link:cookiecutter.json[role=include]
}

build_in_ci

definition

Do you want to build docker images in CI for deployment?

Note
 Requires a docker registry. 
{
link:cookiecutter.json[role=include]
}

use_auto_deploy

Do you want to use automatic deployments?

definition
{
link:cookiecutter.json[role=include]
}