Optional expiration date on revisions?

store
1

Hi all,

I’m working on publishing snaps of Multipass from pull requests, and having doubts about whether to use the snap store for this.

On the one hand, this looks awesome:

$ snap install multipass --channel edge/pr-123
# or even
$ snap install multipass_123 --channel edge/pr-123

On the other, I feel like doing this for every push to a pull request will mean pushing a lot of temporary snaps to the store, and today there is no expiration on them.

What do you think about optionally setting an expiration date on revisions? The store could garbage-collect revisions that are not published on any active channel and whose expiration date passed.

It just feels like dead weight to keep those forever…

2

Hey,

but that doesn’t mean it’ll always be so. We have recognized that a lot of snaps that are unlikely to ever be installed are pushed, consuming storage and resources, and have long been considering a strategy to reap them to reclaim those resources. This is still being considered and designed because there are a bunch of factors to keep in mind and implications to ponder. So no worries, we’ll get there in due time :slight_smile:

  • Daniel
3

Oh well, let this thread be input into that design! :slight_smile:

I must say the parallel install story grows on me more and more for this use case:

  1. you snap install <snap>_123 --channel edge/pr-123
  2. find and report some issues in the review, wait for feedback
  3. you get the feedback, and see the code got updated on the PR
  4. hey presto! it’s already installed under <snap>_123 for you :slight_smile:
2 Likes
4

Would developers be able to go back to an earlier (not necessarily the previous) revision in the edge/pr_123 channel? That would be ideal, to enable examining deltas in the same PR.

5

Yes, collaborators can access any existing revision with snap refresh <snap> --revision <number>, and find the available ones in snapcraft revisions <snap>.