stack/.github/workflows/deploy-website.yml at main · codename-co/stack · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
name: Deploy website

# Builds stack.lol and publishes it to GitHub Pages.
#
# This replaces `make deploy` (rsync to the private minicloud box), which could
# only run from a laptop with SSH access. The Pages deployment is reproducible
# and needs no credentials beyond the workflow's own OIDC token.
#
# The scheduled run exists because the site embeds content that ages (release
# metadata, generated listings) even when nothing is pushed.

on:
  push:
    branches: [main]
    paths:
      - "hub/**"
      - "recipes/**"
      - "packages/website/**"
      - "packages/scripts/**"
      - ".github/workflows/deploy-website.yml"
  schedule:
    # Off-peak, and off the hour to avoid the scheduler's busiest minute.
    - cron: "17 4 * * *"
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

# One deployment at a time, and never cancel one in flight: a half-published
# Pages deployment would leave the live site inconsistent.
concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    steps:
      # fetch-depth 1 is enough: pack-stacks.sh identifies content by git *tree*
      # hash, which a shallow clone carries for the checked-out commit.
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install dependencies
        run: npm ci

      # The key changes whenever any hub/recipe content changes, so each such
      # commit writes a new immutable cache entry instead of mutating one.
      # restore-keys then pulls the newest previous store, and because bundles
      # are content-addressed only the apps that actually changed get re-tarred.
      # On the daily scheduled run the key hits exactly and packing is a no-op.
      - uses: actions/cache@v4
        with:
          path: .cache/stacks
          key: stacks-v1-${{ runner.os }}-${{ hashFiles('hub/**', 'recipes/**', 'packages/scripts/bundle-recipe.ts', 'packages/scripts/pack-stacks.sh') }}
          restore-keys: |
            stacks-v1-${{ runner.os }}-

      # Invoked through `bash` on purpose: the repo has core.fileMode=false on
      # some clones, so the executable bit is not guaranteed to survive a commit.
      - name: Pack stacks
        run: bash ./packages/scripts/pack-stacks.sh

      # GITHUB_TOKEN lifts the anonymous 60 req/h limit on the two calls the
      # build makes to resolve the latest release (download link + the updater
      # manifest mirrored at /releases/latest.json).
      - name: Build website
        env:
          GITHUB_TOKEN: ${{ github.token }}
        run: cd packages/website && npm run build

      - uses: actions/configure-pages@v5

      # dist is ~500MB, dominated by the .stack bundles — under the 1GB Pages
      # artifact limit. Note that `packages/website/public/releases` is
      # deliberately absent (and gitignored): the download page redirects to
      # GitHub Releases, so the DMGs are never part of this artifact.
      - uses: actions/upload-pages-artifact@v3
        with:
          path: packages/website/dist

      - uses: actions/deploy-pages@v4
        id: deployment