bridgy-fed/app.yaml

# https://cloud.google.com/appengine/docs/standard/python/config/appref

# application: bridgy-federated

runtime: python39

# default_expiration: 1h

# https://cloud.google.com/appengine/docs/standard/python3/runtime#entrypoint_best_practices
# https://docs.gunicorn.org/en/latest/settings.html#timeout
entrypoint: gunicorn --workers 1 --threads 10 --timeout 60 -b :$PORT app:app

# background: https://github.com/snarfed/bridgy/issues/578
# https://github.com/snarfed/bridgy/issues/1051
automatic_scaling:
  max_idle_instances: 1
  target_cpu_utilization: .9
  min_pending_latency: 3000ms
  max_concurrent_requests: 30

inbound_services:
- warmup

handlers:

# static
- url: /static
  static_dir: static
  secure: always

- url: /oauth_dropins_static
  static_dir: oauth_dropins_static

- url: /fonts
  static_dir: oauth_dropins_fonts

- url: /favicon.ico
  static_files: static/favicon.ico
  upload: static/favicon.ico
  secure: always

- url: /robots.txt
  static_files: static/robots.txt
  upload: static/robots.txt
  secure: always

# dynamic
- url: .*
  script: auto
  secure: always
initial setup 2017-08-12 23:51:48 +00:00			`# https://cloud.google.com/appengine/docs/standard/python/config/appref`

rename: bridgy-activitypub => bridgy-federated ...merging with bridgy-ostatus! 2017-08-14 14:56:49 +00:00			`# application: bridgy-federated`
temporarily disable actually deleting Followers on AP Delete requests mastodon.social sends Deletes for every Bridgy Fed account, all at basically the same time, and we have many Follower objects, so we have to do this table scan for each one, so the requests take a long time and end up spawning extra App Engine instances that we get billed for. and the Delete requests are almost never for followers we have. TODO: revisit this and do it right. 2020-10-11 15:32:55 +00:00
upgrade to python 3.9 runtime and feedparser 6.0.2 2021-03-06 16:03:36 +00:00			`runtime: python39`
temporarily disable actually deleting Followers on AP Delete requests mastodon.social sends Deletes for every Bridgy Fed account, all at basically the same time, and we have many Follower objects, so we have to do this table scan for each one, so the requests take a long time and end up spawning extra App Engine instances that we get billed for. and the Delete requests are almost never for followers we have. TODO: revisit this and do it right. 2020-10-11 15:32:55 +00:00
migrate to the app engine standard python 3 runtime! https://cloud.google.com/appengine/docs/standard/python3/python-differences https://cloud.google.com/appengine/docs/standard/python/migrate-to-python3/ 2019-12-26 06:20:57 +00:00			`# default_expiration: 1h`
initial setup 2017-08-12 23:51:48 +00:00
migrate to the app engine standard python 3 runtime! https://cloud.google.com/appengine/docs/standard/python3/python-differences https://cloud.google.com/appengine/docs/standard/python/migrate-to-python3/ 2019-12-26 06:20:57 +00:00			`# https://cloud.google.com/appengine/docs/standard/python3/runtime#entrypoint_best_practices`
			`# https://docs.gunicorn.org/en/latest/settings.html#timeout`
flask: move app to app.py, get templates working, port /responses 2021-07-07 15:07:20 +00:00			`entrypoint: gunicorn --workers 1 --threads 10 --timeout 60 -b :$PORT app:app`
initial setup 2017-08-12 23:51:48 +00:00
app config autoscaling changes to try to keep instance count down snarfed/bridgy#1051 2021-07-01 20:27:26 +00:00			`# background: https://github.com/snarfed/bridgy/issues/578`
flask: start porting render.py 2021-07-06 03:54:23 +00:00			`# https://github.com/snarfed/bridgy/issues/1051`
app config autoscaling changes to try to keep instance count down snarfed/bridgy#1051 2021-07-01 20:27:26 +00:00			`automatic_scaling:`
			`max_idle_instances: 1`
			`target_cpu_utilization: .9`
			`min_pending_latency: 3000ms`
			`max_concurrent_requests: 30`

turn on App Engine warmup requests https://cloud.google.com/appengine/docs/standard/reference/app-yaml?tab=python#inbound_services 2022-11-15 19:36:38 +00:00			`inbound_services:`
			`- warmup`

initial setup 2017-08-12 23:51:48 +00:00			`handlers:`

			`# static`
			`- url: /static`
			`static_dir: static`
add secure: always to static file routes 2017-08-19 20:30:54 +00:00			`secure: always`
initial setup 2017-08-12 23:51:48 +00:00
switch oauth_dropins symlink to oauth_dropins_static, drop it from repo it's now local clone only. this avoids import confusion, ie whether importing oauth_dropins uses the virtualenv's installed version or the symlinked files directly, which eg ran oauth-dropins's tests along with granary's/bridgy's, and caused Circle breakages like https://app.circleci.com/pipelines/github/snarfed/granary/767/workflows/21608f75-bb99-47dc-83ef-78d4f4793ed1/jobs/2819 corresponds to snarfed/granary@00294822d61765235a17eeb72ccd74dc2c231abb, snarfed/bridgy@b3f50d82489e85b14a8ef58a3abd0714cae85b4d 2021-08-06 18:19:33 +00:00			`- url: /oauth_dropins_static`
			`static_dir: oauth_dropins_static`
minor config changes for let's encrypt certbot, stub index.html 2017-08-16 14:47:21 +00:00
lots of UI tweaks 2022-11-13 07:19:09 +00:00			`- url: /fonts`
			`static_dir: oauth_dropins_fonts`

start on home page html, style, and assets 2017-08-18 14:31:31 +00:00			`- url: /favicon.ico`
			`static_files: static/favicon.ico`
			`upload: static/favicon.ico`
add secure: always to static file routes 2017-08-19 20:30:54 +00:00			`secure: always`
start on home page html, style, and assets 2017-08-18 14:31:31 +00:00
			`- url: /robots.txt`
			`static_files: static/robots.txt`
			`upload: static/robots.txt`
add secure: always to static file routes 2017-08-19 20:30:54 +00:00			`secure: always`
initial setup 2017-08-12 23:51:48 +00:00
			`# dynamic`
migrate to the app engine standard python 3 runtime! https://cloud.google.com/appengine/docs/standard/python3/python-differences https://cloud.google.com/appengine/docs/standard/python/migrate-to-python3/ 2019-12-26 06:20:57 +00:00			`- url: .*`
			`script: auto`
webfinger: handle /.well-known/webfinger, salmon link bug fix 2017-08-27 18:53:48 +00:00			`secure: always`