@dcaro: Is there some overlap / duplication with T134494: Create a "my first Python webservice" tutorial for Toolforge?

In T331724#8683449, @Aklapper wrote:

@dcaro: Is there some overlap / duplication with T134494: Create a "my first Python webservice" tutorial for Toolforge?

There is yes :), though this task is focused on doing so with buildpacks (that is not yet released), but eventually yes, it will be the same once the toolforge build service is released.

How will secrets work with buildpacks? The previous recommendation was to create a config file inside the tool account and change the permissions so that only the tool user could read it. But now the code will be cloned directly from a git repo and baked into the application image, so this wouldn't work. On Heroku, configuration is managed via "config vars" that can be set and unset via their CLI tool or the web UI. These are exposed as environment variables to the running application.

From the Heroku docs: https://devcenter.heroku.com/articles/django-assets

WhiteNoise
Django does not support serving static files in production. However, the fantastic WhiteNoise project can integrate into your Django application, and was designed with exactly this purpose in mind.

See the WhiteNoise Django documentation for more details.

There is also a full example settings.py in the Getting Started with Python project on GitHub.

Collectstatic during builds
When a Django application is deployed to Heroku, $ python manage.py collectstatic --noinput is run automatically during the build. A build will fail if the collectstatic step is not successful.

Will this apply to our use case of Heroku buildpacks too?

The app when started by toolforge will run as the tool user, and the home will be mounted at the same place it is now, so it will be able to read the config the same way it does now.

I have not personally tested it yet, but that is the idea, so the secrets process would not change (yet!)

Published here: https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Ongoing_Efforts/Toolforge_Build_Service/Documentation/Django_app

Maybe the repository should go to gitlab under toolforge-repos? (like https://gitlab.wikimedia.org/toolforge-repos/sample-php-buildpack-app)