Prepare recipe release #14
Reference in New Issue
Block a user
Delete Branch "recipe-release"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #13
@@ -38,1 +4,4 @@# choose what flavour of Bonfire to run. default: social#APP_FLAVOUR=social# uncomment to run specific version e.g. v1.0.4 or latest release branch. available: latest, latest-beta, latest-alphaalso latest-rc
and version without the v, eg: 1.0.4
@@ -69,2 +53,2 @@# and do not check your env file into any public git repo# change ALL the values:# recommended search backend sonicCOMPOSE_FILE="$COMPOSE_FILE:compose.sonic.yml"should this be uncommented by default, given they make skip giving sonic a PW, so could be one step in docs: uncomment these two lines and set a PW to enable search
@@ -71,0 +62,4 @@# ====================================# MAIL# Enable `compose.mail.yml` to set secrets for sending emails (remember to also include your chosen search backend's compose file):is the reminder unnecessary since doing
COMPOSE_FILE="$COMPOSE_FILE:?@@ -78,4 +75,2 @@# signup to an email service and edit with relevant info, see: https://docs.bonfirenetworks.org/Bonfire.Mailer.html# MAIL_DOMAIN=mgo.example.com# MAIL_KEY=xyz# NOTE: please add `compose.mail.yml` to COMPOSE_FILE above and use the abra secret instead of env for secrets ^seems like an invalid char here?
@@ -116,3 +113,3 @@# Enable using Bonfire as an SSO provider for external apps to sign in with?# ENABLE_SSO_PROVIDER=falseOAUTH_ISSUER=https://${DOMAIN}#OAUTH_ISSUER=https://${DOMAIN}can uncomment by default?
Is it necessary to uncomment by default? what for?
for the OAuth & OpenID provider (different from the clients that are in seperate compose files)
ok, but does every instance need this?
I guess we can instead do it in code from the domain, and leave it commented for people who want to override
I guess I'm fine uncommenting it. I was just wondering if the oauth issuer is always active on every instance and this env var works as the switch to activate it.
@@ -127,4 +125,4 @@# OPENID_1_ENABLE_SIGNUP=false# ^ can be code, token or id_token# orcid.org SSO: connect as a client to the orcid.org OpenID Connect provider with callback url https://yourinstance.tld/oauth/client/orcidurl changed to https://yourinstance.tld/openid/client/orcid
@@ -118,3 +115,3 @@OAUTH_ISSUER=https://${DOMAIN}#OAUTH_ISSUER=https://${DOMAIN}# OpenID Connect: connect as a client to the OpenID Connect provider with callback url https://yourinstance.tld/oauth/client/openid_1url changed to https://yourinstance.tld/openid/client/openid_1
@@ -144,3 +145,3 @@# SECRET_GITHUB_CLIENT_SECRET_VERSION=v1# GITHUB_APP_CLIENT_ID=# GITHUB_CLIENT_SECRET=can add one more
@@ -148,0 +152,4 @@#SECRET_GHOST_CONTENT_API_KEY_VERSION=v1#SECRET_GHOST_ADMIN_API_KEY_VERSION=v1#GHOST_URL=https://example.ghost.io#IFRAME_ALLOWED_ORIGINS=https://example.comIFRAME_ALLOWED_ORIGINS is not specific to just ghost, but in general what websites you want to allow embeding a bonfire widget in iframe
@@ -0,0 +1,68 @@version: '3.8'x-postgres-env: &postgres-envcurious what this does?
@@ -0,0 +8,4 @@services:app:environment:<<: *postgres-envah I see!
@@ -0,0 +18,4 @@command: >postgres-c max_connections=200-c shared_buffers=${DB_MEMORY_LIMIT}MBshould we put a default for DB_MEMORY_LIMIT as fallback?
also good to add PG_STORAGE_TYPE, DISK_STORAGE_TYPE and PG_RAM_PERCENT, and in general may be useful to rebase as quite a few changes were made (including default tuning on this compose for anyone not using the autotune one)
@@ -0,0 +17,4 @@image: ${DB_DOCKER_IMAGE:-ghcr.io/baosystems/postgis}:${DB_DOCKER_VERSION:-17-3.5}command: >postgres-c max_connections=200maybe max_connections can be changed in ENV?
@@ -0,0 +28,4 @@- type: tmpfstarget: /dev/shmtmpfs:size: 1000000000maybe size can be changed in ENV?
@@ -0,0 +31,4 @@size: 1000000000# about 1 GB in bytestmpfs:- /tmp:size=${DB_MEMORY_LIMIT}M^ditto
@@ -0,0 +13,4 @@- UPLOADS_S3_DEFAULT_URL- UPLOADS_S3_URL_EXPIRATION_TTL- AWS_ROLE_ARN- AWS_WEB_IDENTITY_TOKEN_FILE=/run/secrets/aws_web_identity_tokenthe token file is optional though
@@ -4,3 +4,3 @@services:app:image: ${APP_DOCKER_IMAGE}image: bonfirenetworks/bonfire:${APP_VERSION:-1.0.4}-${APP_FLAVOUR:-social}-${APP_PLATFORM:-amd64}I'd like to keep the
bonfirenetworks/bonfirepart in ENV too, so people can use a fork / custom flavour@@ -31,1 +23,3 @@- APP_NAME- LANG=${LANG:-en_US.UTF-8}- SEEDS_USER=${SEEDS_USER:-root}- ERLANG_COOKIE=${ERLANG_COOKIE:-bonfire_cookie}can we change this to set RELEASE_COOKIE_FILE with a secret? and add RELEASE_DISTRIBUTION, RELEASE_NODE, RELEASE_MODE in env (these are for running multi-node deployments)
@@ -67,4 +45,1 @@- WEB_PUSH_PUBLIC_KEY- WEB_PUSH_PRIVATE_KEY- AKISMET_API_KEYthese four are secrets
you mean all the api keys? so I would put OTEL_HONEYCOMB_API_KEY and OTEL_LIGHTSTEP_API_KEY in one yml, AKISMET_API_KEY in one and MAPBOX_API_KEY in another.
@@ -0,0 +11,4 @@- ghost_content_api_key- ghost_admin_api_keysecrets:need an extra secret: GHOST_WEBHOOK_SECRET
@@ -0,0 +6,4 @@- GHOST_URL- GHOST_CONTENT_API_KEY_FILE=/run/secrets/ghost_content_api_key- GHOST_ADMIN_API_KEY_FILE=/run/secrets/ghost_admin_api_key- IFRAME_ALLOWED_ORIGINSthis should be on main compose