Documents & Static Content: The Repo → SharePoint Pipeline

Lesson 10: Documents & Static Content — The Repo → SharePoint Pipeline

You asked the sharpest question of the course: can a GitHub repo act as the document repository that feeds SharePoint? Yes — with one crucial framing decision that determines whether your life is easy or miserable: decide the system of record per artifact type, then publish one way.

Where documents should live (the consensus)

Concretely: PDFs, Word/Excel finals, and official materials belong in SharePoint libraries. Code, templates, scripts, and the markdown source of documents belong in git. Binaries that only exist for distribution (release artifacts) can be pushed from CI and forgotten.

The mechanisms: verified commands

Uploading a file into a library with metadata is a solved problem in both tools. The essential set:

An end-to-end "docs folder → library" pipeline

Triggered only when docs/ changes, this workflow walks every file in the folder and publishes it to Shared Documents/<repo-folder> using the PnP PowerShell OIDC action from Lesson 8 (no certificate secret needed):

name: Publish docs to SharePoint

on:
  push:
    branches: [ main ]
    paths: [ 'docs/**' ]        # runs only when the docs folder changes

permissions:
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Publish docs via PnP PowerShell
        uses: anoopt/action-pnp-powershell-with-oidc@v1.3.0
        with:
          TENANT_ID: ${{ secrets.TENANT_ID }}
          TENANT_NAME: ${{ secrets.TENANT_NAME }}
          CLIENT_ID: ${{ secrets.CLIENT_ID }}
          SITE_URL: "https://contoso.sharepoint.com/sites/intranet"
          PNP_POWERSHELL_SCRIPT: |
            $root = "Shared Documents/Published Docs"
            $files = Get-ChildItem -Path "./docs" -Recurse -File
            foreach ($file in $files) {
              # mirror the repo subfolder structure inside the library
              $rel = $file.FullName.Substring((Get-Location).Path.Length + 1)
              $target = Join-Path $root (Split-Path $rel -Parent)
              Resolve-PnPFolder -SiteRelativeFolder $target | Out-Null
              Add-PnPFile -Path $file.FullName -Folder $target `
                -FileName $file.Name -Values @{ Source = "github" }
            }

Same shape with CLI for Microsoft 365: run m365 login --authType certificate … (Lesson 8's flags), then loop m365 spo folder add + m365 spo file add per file. Prefer the scripted route when you need metadata, content types, or exact behavior; it's fully under your control and uses the same auth you already set up.

Marketplace actions for repo → library sync

Rule of thumb: scripted CLI/PnP for control, Mirror Sync for "keep this folder in sync," and treat any action with deprecated auth as radioactive.

Static content for pages — and the "is SharePoint a website host?" question

"Static content" for SharePoint usually means images, CSS, JS, or HTML that pages and web parts reference. Your options, in order of fit:

• Bundled with SPFx (Lesson 3–5): assets travel inside the .sppkg. Best for component assets — no external hosting at all.
• Document library + SharePoint CDN (intranet): enable the library as a CDN origin (m365 spo cdn origin add --originUrl "<site>/Shared Documents/cdn" --type Private; also a Public type) and reference assets by CDN URL. Private is right for internal content; m365 spo cdn get / policy manage it.
• External host (public): GitHub Pages, Azure Static Web Apps, or blob storage + CDN. Use these when the content must be reachable outside your tenant.

Deciding what goes where

Further Reading

• m365 spo file add (CLI for Microsoft 365)
• Add-PnPFile (PnP PowerShell reference)
• m365 spo cdn origin add — enable a library as a CDN origin
• SharePoint developer documentation (Microsoft Learn)