GCS

1. Set the bucket in settings.py 1. Store your Service Account JSON in a file 1. Set GOOGLE_APPLICATION_CREDENTIALS to your account file 1. Set GCS_BUCKET to your bucket name

SAML2

Please familiarise yourself with Shibboleth configuration and the general flow of how to register a SP with an IDP.

If you send the SP metadata statically, validity time must be removed.

You will also need to register your IDP metadata here either statically or remotely updated.

You may consider testing with testshib.

Configure signing and encryption keys, and configure them in the settings.py

Making migrations

If you make changes to the data model, you'll need to run "manage.py makemigrations" to create a matching migration file. If you're on a mac, or a system without python3, this can be difficult.

In such a case, you can use the above script to make and run a dev container; then:

docker exec -it symposion ./manage.py makemigrations

Pre-post-start configuration

Now that we are ready to start the app, we need to do initial setup, start it, perform voodoo string magic, run more database jingling voodoo, and then we can start it up and start looking around and customising the application.

<tt class="docutils literal">./manage.py migrate</tt> <tt class="docutils literal">./manage.py runserver</tt>

Now we hit up the admin interface, find <cite>symposion_proposals</cite> <cite>proposalkind</cite> and add <cite>Talk</cite> slug <cite>talk</cite>, <cite>Tutorial</cite>:<cite>tutorial</cite>, and <cite>Miniconf</cite>:<cite>miniconf</cite>.

Shut down and now run: <tt class="docutils literal">./manage.py populate_inventory</tt>

Now you can run the system and see how it goes.

Admin Credentials

To create a local administrator account run:

<tt class="docutils literal">./manage.py createsuperuser</tt>

and enter your username, email and password. This can then be used to login to: (http://localhost:8000/admin).

Base Data

On initial creation and whenever you reset the database you must reload the basic data. This data is stored in the /fixtures directory. You can load this with:

<tt class="docutils literal">./manage.py loaddata ./fixtures/{conference,sites,sitetree,flatpages}.json</tt>

And to load the base admin users:

<tt class="docutils literal">./manage.py loaddata ./fixtures/admin_users.json</tt>

admin1:Inq4JVQyQvWnqXDI

admin2:w0jYMJsM4S+1zHds

admin3:XzynbNH9Sw3pLPXe

Creating review permissions objects

After conference Sections have been created, this command will add Permission objects for those sections.

<tt class="docutils literal">./manage.py create_review_permissions</tt>

CI/CD Workflow

4 stages:

1. Dev Review apps
2. dev.lca2019.org
3. staging.lca2019.org
4. linux.conf.au/lca2019.org (not yet live)

• Driven by <cite>.gitlab-ci.yml</cite>

Stages 1 and 2 use sqlite databases; fixtures in the repo are loaded when the container starts but there is no persistent storage - except that stage 2 has some persistence of admin accounts. Stages 3 and 4 have (seperate) mysql backends which persist between deploys.

Stages 2-4 use SSO for login; stage 1 has admin accounts defined in fixtures.

All commits to any dev/* branch create a dev review app; for instance, a commit on dev/tchaypo/reviewapps becomes available at http://dev-tchaypo-reviewapps.dev.lca2019.org (for now you'll need to add <cite>35.189.5.101 dev-tchaypo-reviewapps.dev.lac2019.org</cite> to /etc/hosts for this to work.)

Once a commit is accepted into <cite>/dev/2019</cite> it will also be auto-deployed to <cite>https://dev.lca2019.org</cite>.

Once it's been tested there and is ready for further testing it can be manually deployed to staging, which gives the first chance to test database migrations and to double-check the MySQL backend.

The CI/CD processes can be monitored through Gitlab's CI/CD page https://gitlab.com/laconfdev/symposion_app/pipelines

Manual deployments (eg, to staging and production) can be initiated from a pipeline's page - eg https://gitlab.com/laconfdev/symposion_app/pipelines/24003091 - after prior stages pass.

Traps for new players

1. Terms and Conditions during ticket purchase workflow are implemented by having a product category called something like "Terms & Conditions" with a product called "I accept". See <cite>settings.TERMS_PRODUCT_CATEGORY</cite> and <cite>pinaxcon/registrasion/management/commands/populate_inventory.py</cite>.

Issues

Couldn't upgrade to Django 3.2 due to <cite>python_2_unicode_compatible</cite> in <cite>pinax-stripe==4.4.0</cite>. Trialed <cite>pinax-stripe-light==5.0.0</cite>, which seems to be it's successor, but it's missing the <cite>pinax.stripe.models.Charge</cite> model.

Got <cite>AssertionError: database connection isn't set to UTC</cite> in development. Fixed by <cite>pip install psycopg2==2.8.6</cite>.