PhiPhi’s Bizarre Aventure

How This Blog Deploys to Alibaba Cloud OSS and CDN

2026-03-10T00:00:00Z

This site is built with Lume and deployed to Alibaba Cloud OSS, with Alibaba Cloud CDN in front of it. The deployment pipeline stays intentionally small: one GitHub workflow, Deno available on the runner, and one custom action that restores a local build cache, runs the build, syncs OSS, and cleans up: frenchvandal/aliyun-oss-cdn-sync-action.

I now want five properties at the same time: short-lived credentials, warmed builds on fresh runners, predictable uploads, cache headers that match the files being shipped, and automatic cache coherence. This setup gives me all five without adding repository-specific deploy scripts.

Pipeline at a glance

In steady-state production, this repository’s workflow now does three things:

Checks out the repository.
Installs Deno with the pinned version from .tool-versions and enables the runner-side tool cache.
Runs the OSS/CDN sync action, which restores _cache, executes deno task build, uploads _site, refreshes CDN, and cleans up.

At the moment, that build also fingerprints the shared and route-scoped critical CSS assets, strips source maps, and prunes optional Pagefind files that are not referenced by the final HTML before _site is synced.

name: Deploy static content to OSS

on:
  push:
    branches: ["master"]
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

concurrency:
  group: "oss-deploy"
  cancel-in-progress: true

jobs:
  deploy:
    environment:
      name: development
    runs-on: macos-26
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Setup Deno environment
        uses: denoland/setup-deno@v2
        with:
          deno-version-file: .tool-versions
          cache: true

      - name: Deploy to Alibaba Cloud OSS
        uses: frenchvandal/aliyun-oss-cdn-sync-action@master
        with:
          role-oidc-arn: ${{ secrets.ALIBABA_CLOUD_ROLE_ARN }}
          oidc-provider-arn: ${{ secrets.ALIBABA_CLOUD_OIDC_PROVIDER_ARN }}
          role-session-name: ${{ github.run_id }}
          role-session-expiration: 3600
          cache-enabled: true
          cache-key: >-
            lume-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('deno.lock') }}-${{ hashFiles('_cache/**/*') || 'empty' }}
          cache-restore-keys: |
            lume-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('deno.lock') }}-
            lume-cache-${{ runner.os }}-${{ runner.arch }}-
          input-dir: _site
          bucket: ${{ secrets.OSS_BUCKET }}
          region: ${{ secrets.OSS_REGION }}
          audience: ${{ github.repository_id }}
          cdn-enabled: true
          cdn-base-url: ${{ secrets.OSS_CDN_BASE_URL }}
          cdn-actions: refresh
          build-command: deno task build

In this repository, I currently keep cdn-actions: refresh. The action still supports refresh,preload, but this site’s workflow no longer enables preload on every deployment.

Why OIDC instead of access keys

The action uses GitHub OIDC to assume an Alibaba Cloud RAM role at runtime. No long-lived access key is stored in the repository. The workflow only needs id-token: write plus the RAM role ARN and the OIDC provider ARN.

Authentication is now OIDC-only. The action does not fall back to static access keys from inputs or environment variables if role assumption fails.

The current setup also passes audience: ${{ github.repository_id }}. GitHub can mint an ID token for a custom audience, and Alibaba Cloud RAM can validate that aud value against the Client IDs configured on the OIDC identity provider and in the role trust policy. That gives me a tighter trust boundary than relying on default audience handling alone.

How the action runs internally

The action is split into three phases:

pre: assumes the RAM role through OIDC and stores temporary credentials in action state.
main: optionally restores the local _cache directory, runs build-command, uploads local files to OSS, applies cache headers, and runs CDN actions if enabled.
post: compares remote objects under the destination prefix with local files produced by the build, deletes remote orphans, refreshes deleted URLs when needed, writes CDN task summaries, and saves _cache when cache-key is configured.

The cleanup phase runs with post-if: always(), so it still executes even when earlier steps fail. Cleanup, CDN calls, and cache restore or save are intentionally best-effort: warnings are logged, but transient CDN or cache service issues do not block the deployment.

Upload, cache, quota, and drift control

A few implementation details matter for reliability:

build-command runs inside the action before any OSS upload or CDN call.
If cache-enabled is true and cache-key is configured, _cache restore happens before the build and a fresh snapshot can be saved during post.
cache-enabled controls only restore, so I can skip warm-cache restore temporarily without giving up the post-step cache save.
Uploads are parallelized with max-concurrency.
A global API throttle is applied through api-rps-limit.
Each file upload is retried up to 3 times before being marked as failed.
Partial upload failures are surfaced through failed-count and the GitHub job summary instead of being buried in the logs.
The upload step now writes Cache-Control headers automatically: HTML and sw.js are revalidated aggressively, hashed assets are uploaded as immutable, and common static assets get shorter revalidation windows instead of a one-size-fits-all policy.
cdn-actions only accepts refresh or refresh,preload; if CDN is enabled and the value is empty or invalid, the action falls back to refresh.
The action checks remaining CDN quota before submitting refresh or preload batches.
Deleted OSS objects can trigger CDN refresh for removed URLs, which reduces stale-cache windows and limits object drift over time.
The action writes a GitHub Actions job summary for deployment, cleanup, and CDN task status.

That last point is easy to miss: upload alone is not enough for a static site that changes over time. You also need deletion and cache invalidation for objects that should no longer exist.

Minimum RAM permissions

At the policy level, the role needs OSS permissions on the target bucket scope for listing, uploading, and deleting objects. On the CDN side, this workflow needs refresh permissions plus the read APIs used for quota checks and task lookups. If preload is enabled, add the corresponding preload permission too. The trust policy must allow the GitHub OIDC provider to assume the deploy role.

I keep this as a dedicated deploy role rather than mixing it with broader operational permissions.

Reusing the action in other repositories

The action is published and reusable: github.com/frenchvandal/aliyun-oss-cdn-sync-action.

This repository currently tracks @master because I maintain the site and the action together. In a separate repository, I would usually pin @v1 or, better yet, a full commit SHA. I also now let the action own the build and _cache lifecycle, which keeps consumer workflows shorter and more declarative.

For me, the key result is that deploys stay boring: restore cache, build, sync, refresh, cleanup, done.

Lorem Ipsum and the Art of Placeholder Text

2026-02-18T00:00:00Z

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Most people know the phrase but few know its origin. It is a scrambled excerpt from Cicero’s de Finibus Bonorum et Malorum, a philosophical treatise written in 45 BC. The text has been used as filler copy since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

Why placeholder text matters

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

When you design a layout with real words, you design for those specific words. Placeholder text forces you to design for the structure, not the content. This is a valuable constraint—it reveals whether your design can accommodate the unexpected: a headline that runs to three lines, a paragraph with no natural break, a word too long for its container.

A question of fidelity

Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam? There is a tension in design between fidelity to real content and the freedom that abstraction permits.

High-fidelity prototypes with real copy require real copy to exist first. Low-fidelity wireframes communicate structure without the distraction of meaning. Both approaches have their place. The key is knowing which tool serves the moment.

// A small utility to generate repeating text blocks.
function lorem(words: number): string {
  const base = "lorem ipsum dolor sit amet consectetur adipiscing elit";
  const tokens = base.split(" ");
  const result: string[] = [];
  for (let i = 0; i < words; i++) {
    result.push(tokens[i % tokens.length] ?? "");
  }
  return result.join(" ");
}

Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.

Conclusion

Lorem ipsum is more than filler. It is a mirror held up to the design—one that reflects structure stripped of meaning, form without content. That is precisely why it endures.

Vestibulum Ante: On Thresholds and New Beginnings

2025-09-04T00:00:00Z

Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae. The Latin word vestibulum—a forecourt, an entrance hall, the space before the door—carries more weight than its English descendant “vestibule” suggests.

A threshold is not an end, nor a beginning. It is the liminal space between the two: the breath held before the first word, the pause after a key turns in a lock. It is where one thing stops and another has not yet started.

The value of the in-between

Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. We live in a culture that devalues transition. We want results, outcomes, the finished thing. The messy middle—the drafts, the doubt, the slow accumulation of understanding—goes undocumented and uncelebrated.

But the in-between is where most of life happens. Commutes. Waiting rooms. The gap between sending a message and reading the reply. The years between knowing what you want and knowing how to get there.

Standing at the door

Fusce suscipit varius mi. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Phasellus viverra nulla ut metus varius laoreet.

I moved to Chengdu on a Tuesday in early autumn. The city was warm in a way that surprised me—not the heat of summer, but the warmth of a place that had already decided it liked you. The streets smelled of chilli oil and osmanthus, and everything felt slightly, pleasantly unfamiliar.

That is what a threshold feels like, I think. Not hostile. Not welcoming. Simply open—waiting to see what you will make of it.

Coda

Quisque sit amet est et sapien ullamcorper pharetra. Vestibulum erat wisi, condimentum sed, commodo vitae, ornare sit amet, wisi. Aenean fermentum, elit eget tincidunt condimentum, eros ipsum rutrum orci, sagittis tempus lacus enim ac dui.

Every document has a vestibulum—the title page, the introduction, the first paragraph. It is the space that prepares the reader for what follows. Write it with care.

Proin Facilisis: Making Things Easier

2025-04-12T00:00:00Z

Proin facilisis—Latin for “promoting ease.” It appears in old botanical texts to describe a plant that aids digestion, smooths a passage, clears an obstruction. As a philosophy for building software, it translates remarkably well.

Good software reduces friction. It anticipates the user’s next step. It provides the right affordance at the right moment. It gets out of the way.

The friction inventory

Proin in tellus sit amet nibh dignissim sagittis. The first step in reducing friction is to map it. Where does the user slow down? Where does attention spike? Where do errors cluster?

In a typical web application, the highest-friction moments are predictable: onboarding, form submission, error recovery, and loading states. These are the vestibules of the product—the thresholds users must cross to reach the value inside.

// Friction shows up in code too.
// Compare these two approaches to handling a missing value:

// High friction—the caller must always check:
function getUser(id: string): User | undefined {/* … */}

// Lower friction—the error is explicit and handled at the boundary:
function getUser(id: string): User {
  const user = db.find(id);
  if (user === undefined) {
    throw new Error(`User not found: ${id}`);
  }
  return user;
}

The paradox of ease

Vivamus pretium aliquet erat. There is a paradox at the heart of “making things easy”: it is very hard to do. Eliminating friction requires deep understanding of the user, the context, and the failure modes. It demands more work from the builder so that less work falls on the user.

This is why ease is a form of generosity. Every unnecessary step you remove from your user’s path is time returned to them—time they can spend on the thing that actually matters.

Facilisis in practice

Donec aliquet metus ut erat semper, et tincidunt nulla luctus. Some principles I return to:

Defaults should be correct for most users, most of the time.
Error messages should explain what went wrong and how to fix it.
The happy path should require no thought.
Configuration should be possible, never required.
Documentation is part of the product.

Nulla facilisi. Phasellus blandit leo ut odio. Nam sed nulla non diam tincidunt tempus. The name of this principle—nulla facilisi, “no easy thing”—is a reminder that ease, properly understood, is never accidental.

How to install this theme?

2022-06-12T00:00:00Z

Simple blog is a clean and minimal blog theme for Lume, with support for tags and authors. It allows you to build your own blog in seconds, and provides Atom and JSON feeds for your subscribers.

The fastest and easiest way to configure this theme is the Lume init command, which you can also copy easily from the Simple Blog theme page. Running:

deno run -A https://lume.land/init.ts --theme=simple-blog

will create a new project with Simple Blog configured. Edit the _data.yml file in your blog root folder with your data to customize the site title, description, and metadata.

Posts must be saved in the posts folder. For example, posts/my-first-post.md.

Install as a remote theme

To add the theme to an existing Lume project, import it in your _config.ts file as a remote module. Update it by changing the version number in the import URL:

import lume from "lume/mod.ts";
import blog from "https://deno.land/x/lume_theme_simple_blog@v0.15.6/mod.ts";

const site = lume();

site.use(blog());

export default site;

Copy the _data.yml file to your blog root folder and edit it with your data.

Customization

You can use lumeCMS to customize the blog and add content easily.