Dataface Tasks
    Heartbeat snapshot (JSON)

    Build GitHub Actions and Pages publisher for Dataface

    IDDASHBOARD_FACTORY-BUILD_GITHUB_ACTIONS_AND_PAGES_PUBLISHER_FOR_DATAFACE
    Statusnot_started
    Priorityp1
    Milestonem4-v1-0-launch
    Ownerdata-analysis-evangelist-ai-training
    Initiativegithub-oss-activity-dashboards

    Problem

    Create an easy-to-copy GitHub Actions workflow and Pages deployment path that refreshes GitHub activity snapshots, runs dft build, and publishes a static dashboard site.

    Context

    • GitHub Pages now supports custom workflow deployment via:
    • actions/configure-pages
    • actions/upload-pages-artifact
    • actions/deploy-pages
    • The deploy job requires pages: write and id-token: write permissions.
    • This initiative needs a setup path that OSS maintainers can copy with minimal hand-holding.
    • The workflow must coordinate three concerns cleanly:
    • refresh data snapshots
    • build the Dataface static site
    • deploy to GitHub Pages
    • The output should be understandable and debuggable by maintainers, not just by Dataface contributors.

    Possible Solutions

    1. Copy-paste workflow only - Very transparent and easy to debug. - Risks drift across adopters and makes upgrades harder.

    2. Recommended: starter workflow plus documented config contract - Keep the workflow readable in the adopting repo, but standardize the config and deployment pattern. - Balances easy adoption with maintainability. - Leaves room for a more packaged reusable workflow later if the contract stabilizes.

    3. Hide everything behind a complex composite action immediately - Clean-looking adoption surface. - Harder to debug and more brittle before the data contract is proven in the wild.

    Plan

    1. Define the workflow stages: checkout, fetch history, extract data, build Dataface outputs, upload Pages artifact, deploy.
    2. Define the minimal config file or environment surface a repo needs to set.
    3. Produce a starter workflow that works in a public OSS repo without external infrastructure.
    4. Document permissions, secrets, cadence, and failure modes.
    5. Verify the workflow against one real reference deployment before calling it ready.

    Implementation Progress

    QA Exploration

    • [ ] QA exploration completed (or N/A for non-UI tasks)

    N/A for browser QA. Verification should focus on workflow execution and static site deployment.

    Review Feedback

    • [ ] Review cleared