Skip to content

feat: juno hosting prune #474

@MAHDTech

Description

@MAHDTech

Overview

I'm volunteering to implement this if the approach looks right/there isn't already the functionality another way.

Let me know if you'd like any changes to the design, I will try and look to implement something over the coming weekend.

Feature

remove stale hosted assets without clearing the entire deployment

Problem

juno hosting deploy is diff-based and only uploads changed files, this is great.

But there's no way to remove files from a live satellite that are no longer in the current build output, without running juno hosting clear (which wipes everything and re-certifies the full site).

For large sites this is painful:

  • --clear re-commits all files in a single proposal, hitting the ICP 40B instruction limit on sites >~80 MB
  • There's a downtime window between the clear and the new deploy applying
  • In the example of An Astro/Vite frontend, the stale files accumulate because Vite content-hashes filenames — old chunks (main.abc123.js) are never overwritten, only orphaned.

Proposed Solution

juno hosting prune

A new subcommand that removes files present on the satellite but absent from the current build output — without touching files still in use.

juno hosting prune [options]

Options:

--dry-run: Show what would be deleted without deleting
--mode: Environment to target (production, staging, development)
-h: --help Output usage information

Algorithm

A work-in-progress, but I'm thinking something like this;

  1. Scan local source directory (from juno.config) → local_files
  2. Fetch live asset list from satellite → live_files
  3. Compute stale = live_files − local_files
  4. Delete stale via change proposal (same mechanism as [deploy]

I'm thinking it would be the inverse of the current deploy's skip logic

  • skips: hash(local) == hash(live)
  • prune deletes: live_file ∉ local_files

Zero Downtime

Only orphaned files are removed.

The satellite always serves a valid, complete set of assets. No window where the site is empty.

CI Usage

Once implement it could be used like this;

- uses: junobuild/juno-action@main
  with:
    args: hosting deploy --mode staging  # commit only new/changed files

- uses: junobuild/juno-action@main
  with:
    args: hosting prune --mode staging   # remove stale chunks, no downtime

Existing Building Blocks

The CLI already has everything needed:

  • Local file scan + hash computation → used by deploy
  • Live asset list fetch → used by deploy to skip unchanged files
  • Single-file delete → exposed by juno hosting clear --fullPath

prune is composing these three existing things.

Questions

  • Is the set-difference approach the right strategy, or is there a simpler internal hook I'm missing?
  • Should deletions go through the change proposal system, or should prune be --immediate by default (since it's non-destructive to live content)?
  • Is there a preferred place in the CLI source to add new hosting subcommands? Happy to follow existing patterns.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions