{
  "$type": "site.standard.document",
  "createdAt": "2022-08-08T21:20:00+01:00",
  "description": "If you want to bust your asset cache whenever a GitHub Action deploys your site, it's actually remarkably easy!",
  "path": "/stream/cache-busting-with-github-actions",
  "publishedAt": "2022-08-08T21:20:00+01:00",
  "site": "at://did:plc:swxoj3wjlwodcqs5ipmvgnug/site.standard.publication/3mnv7gbn3czno",
  "tags": [
    "Code",
    "GitHub"
  ],
  "textContent": "Chris Coyier brought up the perennial problem of cache busting on websites lacking a build step the other week on Shop Talk Show (and blogged about it, too)—and rightly commented that everyone & their dog has their own cache busting solution. Well I've got a dog & a cache busting solution too. Modern JavaScript frameworks, and frameworks with asset pipelines (like Rails) usually come with cache busting built in. That is, when a new bundle is built, the framework will automatically add (usually) a querystring to the <link> tag that imports that bundle—which tells your browser that the bundle has changed and to re-download the bundle from the server. <link rel=\"stylesheet\" href=\"/style.css?v=12345\" /> However, if you don't have a build step—if you're using PHP, for instance, where that <link> tag is generated afresh on every page load—then busting your assets becomes a little bit more complicated. Chris's solution is to put a magic string in his template, and then leverage Buddy, his deployment platform, to run a find & replace on the template, swapping out his magic string for the number of the current deployment <!-- This... --> <link rel=\"stylesheet\" href=\"/style.css?v={{{VERSION}}}\" /> <!-- ...becomes this --> <link rel=\"stylesheet\" href=\"/style.css?v=5\" /> However! Buddy starts at $75/mo, and I don't have that kind of dough. Luckily for me and you, you can do almost the exact same thing with GitHub Actions. I already use GitHub Actions for an extremely simple deployment pipeline on most PHP applications: 1) SSH into the VPS, 2) cd into the right directory, 3) run a git pull and composer install. Bada-bing bada-boom. Once your action is running on your server, you can use sed to do the find & replace for you; GitHub exposes the action run number in its environment variables. The hard part is just chaining it all up. name: Deploy to labs on: push: branches: main jobs: deploy: name: Deploy runs-on: ubuntu-latest steps: - name: Set version string uses: appleboy/ssh-action@master with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} key: ${{ secrets.KEY }} port: ${{ secrets.PORT }} script: cd ${{ secrets.DIRECTORY }} && grep -rl '{{{VERSION}}}' ./templates | xargs sed -i 's/{{{VERSION}}}/${{ github.run_number }}/g' I'll assume that you have other jobs running on GitHub Actions, but hopefully the above is clear: I'm using appleboy/ssh-action to SSH into my VPS (with the credentials in secrets), then cding into the right directory, grepping only the files that contain the magic string ({{{VERSION}}}), and then using sed to swap out the magic string with the current run number. Pretty nifty!",
  "title": "Cache busting with GitHub Actions",
  "updatedAt": "2022-08-08T21:49:11+01:00"
}