Source Sync

Working Folders

Two folders are in play when maintaining the DBR:

Folder Purpose
5g-emerge-testbed-website/ The git repository (DBR). All version-controlled content: markdown status cards, reference docs, templates, dashboard HTML.
5G-EMERGE Testbed Website/ Working directory only — nothing else goes here.
5G-EMERGE Testbed Website/cache/ SharePoint source file cache. Local copies of TVR, SAI, GTL, CTM, STM. Not version-controlled; persists between sessions.
5G-EMERGE Testbed Website/outputs/ Generated binary deliverables not tracked in git (e.g. .xlsx files).

Repository structure

5g-emerge-testbed-website/
├── src/
│   ├── _data/                          ← global data files (site.ts, docSections.ts, …)
│   ├── _includes/                      ← layouts and partials
│   ├── assets/                         ← CSS, JS, images
│   ├── documentation/
│   │   ├── testing/                    ← testing reference docs
│   │   ├── telemetry/                  ← telemetry docs (placeholder)
│   │   └── admin/                      ← admin/internal docs
│   └── testing/                        ← testing section landing
├── status/
│   ├── S2/  (Strand 2 — Cross-infrastructure)
│   ├── S3/  (Strand 3 — DTH)
│   ├── S4/  (Strand 4 — DTV)
│   ├── S5/  (Strand 5 — DTE)
│   └── S6/  (Strand 6 — DTD)
├── dist/                               ← build output; do not edit directly
├── templates/
│   └── test-status-card.md             ← blank card template
├── eleventy.config.ts
└── package.json

Sync Overview

A small Node script copies the latest versions of five source documents from a locally-synced OneDrive copy of the EBU SharePoint library into the local cache directory. This keeps the working copies current so that test status cards, reference pages, and data outputs are always derived from the most recent published versions.

The script does not talk to SharePoint directly. The OneDrive desktop client handles the SharePoint ↔ Mac sync; npm run sync is then a fast local file copy with mtime preservation. No authentication, no API tokens, no third-party app registration.

The authoritative list of source documents and their SharePoint locations is maintained in the Information Sources page.


Prerequisites

The EBU SharePoint library must be synced locally via the OneDrive desktop client. On macOS the synced folder lives under:

~/Library/CloudStorage/OneDrive-SharedLibraries-EBU/5G-EMERGE_Phase 2 - WP 1.2 - Architecture/

To set this up: open the WP 1.2 – Architecture folder in SharePoint in a browser, click the Sync button in the toolbar, and approve the OneDrive prompt. The folder will then appear under CloudStorage and stay in sync in the background.

If your synced folder lives elsewhere, set the ONEDRIVE_ROOT environment variable when running the script (see below).


Running the Sync

npm run sync
# or
npx tsx scripts/sync-cache.ts

The script copies each source file from the OneDrive folder to the cache, preserving modification times so that subsequent runs report "up to date" until the source actually changes.

By default the cache lives at ../5G-EMERGE Testbed Website/cache/ (the sibling Cowork working folder). Override either path with environment variables:

ONEDRIVE_ROOT=/path/to/synced/folder npm run sync
CACHE_DIR=/path/to/cache npm run sync

Example output:

5G-EMERGE source sync
──────────────────────────────────────────────────
Source: /Users/.../OneDrive-SharedLibraries-EBU/5G-EMERGE_Phase 2 - WP 1.2 - Architecture
Cache:  /Users/.../5G-EMERGE Testbed Website/cache

[TVR]  5G-EMERGE_P2_Testing, Validation and Results(TVR)_v2.3.docx  …  copied  (8663 KB)
[SAI]  DO NOT CHANGE_…(SAI)_v2.2.docx  …  copied  (13847 KB)
[GTL]  Global Test List-TVR 5G-Emerge-v3.xlsx  …  copied  (45 KB)
[CTM]  Component to Testbed Mapping (Strand 2).xlsx  …  copied  (24 KB)
[STM]  Scenario to Test Bed Mapping.xlsx  …  copied  (22 KB)

──────────────────────────────────────────────────
Summary

  ⬇   TVR    copied         8663 KB — modified Fri, 10 Apr 2026 15:22:12 GMT
  ⬇   SAI    copied         13847 KB — modified Tue, 31 Mar 2026 11:49:59 GMT
  ⬇   GTL    copied         45 KB — modified Fri, 10 Apr 2026 09:39:31 GMT
  ⬇   CTM    copied         24 KB — modified Fri, 10 Apr 2026 10:31:27 GMT
  ⬇   STM    copied         22 KB — modified Fri, 10 Apr 2026 14:10:39 GMT

The script reports each file as copied (newer than the cached copy or absent from the cache), up to date, or error (source missing).


Source Files

Currently tracked

Acronym Filename Last confirmed
TVR 5G-EMERGE_P2_Testing, Validation and Results(TVR)_v2.3.docx 10 Apr 2026 15:22 UTC
SAI DO NOT CHANGE_5G-EMERGE_P2_Service Architecture and Interfaces (SAI)_v2.2.docx 31 Mar 2026 11:50 UTC
GTL Global Test List-TVR 5G-Emerge-v3.xlsx 10 Apr 2026 09:39 UTC
CTM Component to Testbed Mapping (Strand 2).xlsx 10 Apr 2026 10:31 UTC
STM Scenario to Test Bed Mapping.xlsx 10 Apr 2026 14:10 UTC

Versioned filenames: TVR, SAI, and GTL include a version number in their filename (e.g. v2.3, v2.2, v3). When a new version is published to SharePoint, the filename will change. The DOCUMENTS array in scripts/sync-cache.ts and the entries below must be updated at that point.

OneDrive paths

Relative to ~/Library/CloudStorage/OneDrive-SharedLibraries-EBU/5G-EMERGE_Phase 2 - WP 1.2 - Architecture/:

Acronym Relative path
TVR TVR - Testing, Validation, and Results/5G-EMERGE_P2_Testing, Validation and Results(TVR)_v2.3.docx
SAI SAI - Service Architecture and Interfaces/DO NOT CHANGE_5G-EMERGE_P2_Service Architecture and Interfaces (SAI)_v2.2.docx
GTL TVR - Testing, Validation, and Results/Global Test List-TVR 5G-Emerge-v3.xlsx
CTM TVR - Testing, Validation, and Results/Component to Testbed Mapping (Strand 2).xlsx
STM TVR - Testing, Validation, and Results/Scenario to Test Bed Mapping.xlsx

SharePoint URLs

Direct URLs to the same files in SharePoint. Use these to open or inspect a document in the browser without navigating the folder hierarchy.

TVR

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/WP%201.2%20-%20Architecture/TVR%20-%20Testing%2C%20Validation%2C%20and%20Results/5G-EMERGE_P2_Testing%2C%20Validation%20and%20Results(TVR)_v2.3.docx

SAI

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/WP%201.2%20-%20Architecture/SAI%20-%20Service%20Architecture%20and%20Interfaces/DO%20NOT%20CHANGE_5G-EMERGE_P2_Service%20Architecture%20and%20Interfaces%20(SAI)_v2.2.docx

GTL

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/WP%201.2%20-%20Architecture/TVR%20-%20Testing%2C%20Validation%2C%20and%20Results/Global%20Test%20List-TVR%205G-Emerge-v3.xlsx

CTM

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/WP%201.2%20-%20Architecture/TVR%20-%20Testing%2C%20Validation%2C%20and%20Results/Component%20to%20Testbed%20Mapping%20(Strand%202).xlsx

STM

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/WP%201.2%20-%20Architecture/TVR%20-%20Testing%2C%20Validation%2C%20and%20Results/Scenario%20to%20Test%20Bed%20Mapping.xlsx

Folder URLs (for browsing)

TVR, GTL, CTM, and STM folder:

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/Forms/AllItems.aspx?id=%2Fsites%2F5g%2Demerge%5Fphase2%2FStrand%201%20%20Research%20coordination%20dissemination%2FWP%201%2E2%20%2D%20Architecture%2FTVR%20%2D%20Testing%2C%20Validation%2C%20and%20Results&viewid=46536309%2Db488%2D4039%2Daaaa%2Dcbaadc2c7182

SAI folder:

https://ebu1.sharepoint.com/sites/5g-emerge_phase2/Strand%201%20%20Research%20coordination%20dissemination/Forms/AllItems.aspx?id=%2Fsites%2F5g%2Demerge%5Fphase2%2FStrand%201%20%20Research%20coordination%20dissemination%2FWP%201%2E2%20%2D%20Architecture%2FSAI%20%2D%20Service%20Architecture%20and%20Interfaces&viewid=46536309%2Db488%2D4039%2Daaaa%2Dcbaadc2c7182

Why This Approach

Earlier attempts of the sync script tried to:

  • download using a browser plugin which was error prone and required manual intervention to move the downloaded file from the default Downloads folder to the cache
  • authenticate against the SharePoint REST API directly using Microsoft device-code login. EBU's tenant conditional access policy returned 401 on file-content endpoints for the public Azure CLI client ID, so the script could authenticate but not download.

OneDrive desktop sync sidesteps the problem entirely: the OneDrive client is a Microsoft-signed first-party app and is already trusted by the tenant. Once the library is synced, the script becomes a plain local file copy — no auth code, no token cache, no third-party Azure AD app to register.


Updating to a New Document Version

When a new version of TVR, SAI, or GTL is published to SharePoint:

  1. Wait for OneDrive to finish syncing the new file (the old version is automatically removed)
  2. Update the filename and sourcePath in the DOCUMENTS array in scripts/sync-cache.ts
  3. Update the filename and OneDrive path tables on this page
  4. Update the SharePoint direct URL for the affected document
  5. Run npm run sync to refresh the cache
  6. The reprocessing task will detect the change on its next run and apply updates / write a changelog entry (or trigger it manually)

Automation

Source maintenance is split into two phases:

Phase 1 — Source Sync (manual)

The sync script requires access to the locally-synced OneDrive folder, which is only available on the user's Mac. It cannot run inside the Cowork sandbox. Run it manually whenever you know source files have changed:

npm run sync

Phase 2 — Reprocessing (automated)

Once files are in the cache, a Cowork scheduled task (5g-emerge-reprocess) detects which files have changed since the last processing run, reads them, compares against the current repo state, and:

  • Applies confident updates to status cards (testbed assignments, responsible partners, KPI targets, test nature, TVR references)
  • Flags ambiguous changes for manual review (new test cases, rewritten descriptions, architecture changes)
  • Writes a changelog entry to Source Changelog

The task uses a state file (cache/.last-processed.json) to track which file versions have already been processed, so repeated runs do not re-report the same changes.

Task ID: 5g-emerge-reprocess Schedule: 0 9 * * 1-5 (weekdays at 09:00) Description: Reprocess changed 5G-EMERGE source documents — diff, apply updates, write changelog.

The task prompt is stored at ../5G-EMERGE Testbed Website/5g-emerge-reprocess-SKILL.md.

State file format

cache/.last-processed.json records the modification time and size of each cached file at the point it was last processed:

{
  "lastRun": "2026-04-13T09:00:00Z",
  "files": {
    "TVR": { "filename": "…", "mtimeMs": 1234567890, "size": 8871159 },
    "SAI": { "filename": "…", "mtimeMs": 1234567890, "size": 14179177 },
    "GTL": { "filename": "…", "mtimeMs": 1234567890, "size": 45766 },
    "CTM": { "filename": "…", "mtimeMs": 1234567890, "size": 24299 },
    "STM": { "filename": "…", "mtimeMs": 1234567890, "size": 22887 }
  }
}

If this file is absent, the reprocessing task treats all cached files as new and writes a baseline entry to the changelog.

What the reprocessor does NOT touch

The reprocessor never modifies execution-related fields in status cards: status, confidence, progress, test run counts, keyFindings, defects, risks, blockers, or actions. These are DBR-only data maintained by the user.

It also never creates new status cards automatically — new test cases are flagged in the changelog for the user to create manually using the card template.


Related Pages