Configuration reference
Keep deployment identity in GitLab and runtime application settings in Azure. Examples here use placeholders and intentionally omit credentials and player contact details.
Function application settings
| Setting | Default | Purpose |
|---|---|---|
TEAM_ABBR | BAL | Team identifier for ESPN and reports; the configured pool remains Ravens-specific |
RESULTS_STORAGE_CONNECTION_STRING | None | Required for public snapshots and private pool-state |
ACS_CONNECTION_STRING | None | Required for real email submissions |
EMAIL_FROM | None | Verified ACS sender address |
EMAIL_TO | None | Fallback recipient when a call supplies no recipient |
SUMMARY_EMAIL_TO | EMAIL_TO | Summary recipient |
SUMMARY_PLAYER_ID | bob_clingan | Summary personalization and browser default selection |
DRY_RUN | false | true exits the scheduled workflow before external work |
HALFTIME_PAYOUT | 50.00 | Dollars earned per verified halftime win |
FINAL_PAYOUT | 50.00 | Dollars earned per verified final win |
Prize settings must be finite, nonnegative decimal amounts with no more than two
decimal places. Values such as 50.00 and 12.50 are valid; -1, NaN, and
0.001 are rejected. Amounts describe earned prizes, not payment status.
The normal workflow sends a summary as well as eligible winner messages, so
configure a valid summary recipient even if all player notify flags are off.
DRY_RUN is an early exit, not a simulation that renders reports or fetches scores.
Timezone and runtime settings
The timer uses 0 0 * * * *. The application handles Eastern calendar dates
explicitly with America/New_York; the host does not need a timezone override.
Do not set WEBSITE_TIME_ZONE or TZ on Linux Consumption or Flex Consumption.
Microsoft does not support these settings on those plans. The older bootstrap
script’s Eastern Standard Time setting should not be copied into this setup.
See Azure’s timezone settings reference.
| Runtime/build setting | Where it comes from |
|---|---|
AzureWebJobsStorage | Function host configuration; separate from the results-storage setting |
| Python 3.11 | Existing provisioning script and pinned CI image |
| Functions runtime v4 | Provisioning and host.json extension-bundle configuration |
SCM_DO_BUILD_DURING_DEPLOYMENT=true | Set by the Function deploy job |
ENABLE_ORYX_BUILD=true | Set by the Function deploy job |
WEBSITE_RUN_FROM_PACKAGE | Removed by the current remote-build deploy job |
Confirm the actual Function runtime in Azure if the resource has been modified outside this repository. A hosting-plan or Python-version change requires review of the locks and deployment configuration.
GitLab CI/CD variables
| Variable | Scope/use | Stored secret? |
|---|---|---|
AZURE_CLIENT_ID | Entra app used by Function deployment | No |
AZURE_TENANT_ID | Tenant for Function deployment | No |
AZURE_SUBSCRIPTION_ID | Subscription containing the Function | No |
AZURE_RESOURCE_GROUP | Existing Function resource group | No |
AZURE_FUNCTION_APP_NAME | Existing Function name | No |
SWA_DEPLOYMENT_TOKEN | Static Web Apps production deployment | Yes |
SWA_HOSTNAME | Hostname without https://, used for the GitLab environment link | No |
SENTRY_DSN | Optional override for the public site’s configured Sentry DSN; an empty value disables reporting | No |
SENTRY_ENVIRONMENT | Sentry environment label; defaults to production | No |
SBOM_SUPPLIER | Application supplier; defaults to Bob Clingan in YAML | No |
Use protected variables for production deployment. The Function variables must be
available to production/function; the website variables to production.
Environment scope * also works when appropriate. Store the SWA token as a masked
secret. Runtime connection strings belong in Azure app settings or Key Vault
references, not in the docs or pipeline YAML.
These values are generated by GitLab and should not be entered manually:
AZURE_OIDC_TOKEN: the Function deployment job’s short-lived identity token.CI_PROJECT_PATHandCI_COMMIT_SHA: SBOM application identity.CI_PAGES_URL: canonical documentation URL used by Starlight and the Pages job.
Public site error reporting
The public site’s Sentry DSN is configured in the repository. Run the website
deployment to enable it in production; no GitLab variable is required. Optionally
override SENTRY_DSN in GitLab with environment scope production, or set it to
an empty value to disable reporting. The deployment generates public/sentry-config.js and tags
events with CI_COMMIT_SHA as the release. The DSN is a public browser identifier;
do not put a Sentry auth token in this variable. The checked-in browser configuration
uses the development environment; deployments default to production.
The site uses Sentry’s pinned browser CDN bundle for uncaught errors, unhandled promise rejections, and caught results-loading errors. Session replay and tracing are not enabled. Default PII collection and breadcrumbs are disabled, and the app does not attach player identities or pool data. See the Sentry JavaScript SDK.
The default DSN appears in both public/sentry-config.js (local previews) and
ci/swa/configure-sentry.cjs (deployment). Update both when changing the default
project. SENTRY_DSN and SENTRY_ENVIRONMENT are read during deployment, so a
variable change takes effect only after another website deployment. Removing the
DSN override restores the repository default; an explicitly empty value disables it.
See local development for preview settings and verification for a test event.
Local configuration
For local Function-host development, create an untracked local.settings.json
with host values appropriate to your environment. Start with DRY_RUN=true.
The worker only reads the Values exported by the Functions host; importing the
Python modules directly does not automatically read that file.
For isolated unit tests, use the locked development environment and the mocks
already in tests/. No production credentials are needed.
See local development for exact commands and Azure setup for identity configuration.