fix: fct_cost_centers missing table crashes dashboard – graceful degradation + tests

[Copilot]

Root cause

When a PR is merged to main, the deploy workflow fires immediately on the push: branches: main trigger and downloads the last successful dbt artifact. If the artifact was built before fct_cost_centers was added to the dbt models (the first deploy after the model is introduced), the table won't exist in the served DuckDB file.

The old code included costCenters in the allDataLoaded truthiness check:

const allDataLoaded = Boolean(
    pullRequestCount && ... && owners && costCenters   // ← bug
);

When the cost-center query throws Catalog Error: Table with name fct_cost_centers does not exist!, costCenters stays undefined and allDataLoaded is permanently false — the entire dashboard is stuck in the loading-spinner state.

Fix

webapp/src/pages/home/Home.tsx

• Replace costCenters in allDataLoaded with !loadingCostCenters.
  The page now becomes ready once the cost-center query finishes (whether it succeeded, errored, or returned empty results).
• Conditionally render the Cost Center SelectBox only when costCenters !== undefined, so the filter is cleanly hidden when the table is absent.

deploy_dashboard_to_github_pages.yml — rebuild database before redeploying

A new rebuild_database job runs dbt build on the self-hosted runner whenever the deploy is triggered by a push/workflow_dispatch, ensuring the database always reflects the latest models before the webapp is deployed. The build job downloads the freshly-produced artifact from this job. When the deploy is triggered by the workflow_run from "Run DBT (daily)", the rebuild job is skipped and the build job downloads directly from the triggering dbt run's artifact (already fresh). A head_branch == default_branch guard on the workflow_run path prevents artifacts from non-default branches being deployed. npm dependencies are installed before the DuckDB artifact is downloaded to eliminate the cache-poisoning data-flow path.

github_contributions/src/github_contributions/plugin.py — warnings for missing credentials

Plugin.initialize() now emits WARNING-level log entries (visible even without debug mode) when GITHUB_TOKEN or GH_ENTERPRISE/ENTERPRISE are absent, giving operators an immediate signal in the dbt build output.

Tests added to prevent regression

Python – github_contributions/tests/

File	Tests
test_api.py	5 tests covering get_cost_centers: happy path, multiple cost centers, empty logins skipped, empty/missing API response
test_plugin.py	4 tests for Plugin._cost_centers_to_df: empty DF when no enterprise, data returned when enterprise is set, _cost_center_users populated correctly, empty set when no enterprise
test_plugin.py	3 tests in TestWarningsOnInitialize: token warning fires, enterprise warning fires, no spurious warnings when both credentials are present
test_plugin.py	3 tests in TestLoadMethodSchema: load("cost_centers") returns correct schema without enterprise; returns populated data with enterprise; raises ValueError for unknown resource

Webapp – webapp/src/

File	Tests
hooks/useQuery.test.ts	3 tests: successful query, loading state, error state (table does not exist)
pages/home/Home.test.tsx	4-case regression suite: dashboard renders despite cost-center error; Cost Center filter hidden when absent; shown when present; loading state still blocks render

CI wiring

• pull_request.yml – new python_tests job (pytest, dbt-duckdb==1.7.2) runs on PRs touching github_contributions/**
• webapp_ci.yml – new Run tests step (Vitest) added after ESLint on PRs touching webapp/**

Checklist

• When adding a Github handle to be tracked that is not yours, request the user to approve the PR

[Jesse Houwing (jessehouwing)]

Copilot can we add a job that rebuilds the database prior to redeploying the web app?

And do we have tests that ensure that as the database is built, the correct data is added?

And that when the GitHub token or GitHub enterprise variables are unavailable a warning is logged while building the database?

[Copilot]

Copilot can we add a job that rebuilds the database prior to redeploying the web app?

And do we have tests that ensure that as the database is built, the correct data is added?
...

Done in 7c8563b. Here's what was added:

1 — Rebuild database before redeploying (deploy_dashboard_to_github_pages.yml)

A new rebuild_database job runs dbt build on the self-hosted runner whenever the deploy is triggered by a push/workflow_dispatch. The build job then downloads the freshly-produced artifact rather than a potentially stale one. When the deploy is triggered by the workflow_run from "Run DBT (daily)", the rebuild job is skipped and the build job downloads directly from the triggering dbt run's artifact (which is already fresh). A head_branch == default_branch guard on the workflow_run path ensures only artifacts from the default branch are used.

2 — Tests that verify data is added correctly

• TestLoadMethodSchema (3 new tests in test_plugin.py): verifies that plugin.load("cost_centers") returns a DataFrame with the correct schema (cost_center_name, user_login) both when enterprise is absent (empty DF, no exception) and when it's configured (data flows through). This covers the Python layer. At the SQL layer, dbt build --fail-fast (run in both the dbt workflow and the new rebuild_database job) already runs the not_null/unique/relationships schema tests defined in the YAML files.

3 — Warnings when credentials are unavailable

plugin.initialize() now emits WARNING-level log lines immediately when GITHUB_TOKEN or GH_ENTERPRISE are absent, so operators see them in the dbt build output without needing debug mode enabled. Three new TestWarningsOnInitialize tests verify the token warning, the enterprise warning, and that no spurious warnings fire when both are present.