21:14 <JacobWeisz[m]> Looks like we might have an interesting Let's Encrypt related thing.

21:23 <JacobWeisz[m]> I suspect the requestor's Sandstorm configuration is valid, it seems to be an issue that Alpha would presumably hit if it was using the new code.

21:43 <isd> Is there a reason why we don't have the GitHub action upload the build tarball as an artifact? Was it a space issue?

21:43 <isd> It would be nice if we ask folks to run builds downloaded from CI, rahter than them having to build from source to test fixes.

21:54 <JacobWeisz[m]> It seemed a bit overkill, tbh.

21:54 <JacobWeisz[m]> Apparently we don't pay for the space either way, fun fact.

21:55 <isd> They do delete them after 90 days.

21:55 <JacobWeisz[m]> But arguably if you make a branch on your fork adding that line in, it should build it, right?

21:56 <isd> Yeah. I may push another commit to that branch just to trigger that. But it's annoying to have to push an extra commit and then later force-push it out

21:56 <JacobWeisz[m]> I think at the time it didn't seem like anyone was going to use them for anything. But since it doesn't cost us anything I suppose there's no harm in re-adding that to the action if you expect to suggest people use them.

21:57 <JacobWeisz[m]> I do kinda like the idea of being able to give someone fixed code then and there (within the hour in this case!!!!)

21:57 <isd> Yeah, I think it would be useful to be able to have a build right there for folks to test from time to time.

22:00 <JacobWeisz[m]> IMHO add it back in that PR and leave it added then. I recall verifying with Kenton it didn't count against the sandstorm-io account's quotas, which was an initial concern.

22:01 <JacobWeisz[m]> If it's a private repo in a org, they bill for storage.

22:02 <isd> If GitHub is covering the storage I say we use it.

22:02 <kentonv> there might be a limit on the total storage though?

22:05 <JacobWeisz[m]> I didn't see anything suggesting there was, but if it isn't billing, I guess what would happen if we hit a limit is it'd stop working until we deleted some stuff?

22:06 <isd> We can delete stuff manually. I think worst case we could write a script to periodically delete stuff sooner than their 90 day horizon.

22:06 <JacobWeisz[m]> Cuz there's a limit for free usage of storage, but the public project stuff just straight up wasn't counting against it.

22:07 <JacobWeisz[m]> I feel deleting stuff manually is likely to be burdensome, Actions is a bit aggressive on running multiple builds for every little push it seems.

22:07 <JacobWeisz[m]> I think the "add it in a commit then force push it away" method is less burden, considering the frequency we need the builds from it.

22:08 <JacobWeisz[m]> But I still don't think at present there's technically any downside to having the Action uploading every single one.

22:08 <JacobWeisz[m]> Except maybe giving Microsoft a reason to not give open source projects tons of free storage and compute.

22:09 <isd> I wonder what they're doing on the backend. You could probably keep it pretty managable using the kind of hash-based chunking and deduping you see in e.g. bup & perkeep, but I don't know of any public project that would be quite suitable for that without modification.

22:10 <isd> ...but you could definitely build something such that a project like ours uploading a couple hundred mb for every build doesn't actually get out of hand.

22:10 <isd> ...since they'd be mostly the same.

22:10 <JacobWeisz[m]> Tarballs probably aren't dedupe friendly, are they?

22:11 <isd> The algos those systems use should probably still work

22:11 <isd> A naive file or block based chunking algorithm would not be very useful.

22:20 <isd> I really want a datastore like this that supports easy deletion (which perkeep does not), since it would make it really easy to just take daily backups of grains without space usage getting out of control.

22:21 <isd> One of many things in my mental backlog

22:38 <isd> Oh, I misremembered, the tarball is "only" 70M

22:47 <JacobWeisz[m]> I still really think on-grain-shutdown backups is the key to quick and low-storage abuse backups.

22:48 <JacobWeisz[m]> Over 95% of my grains are not used... ever, they're just stored documents.

22:48 <isd> Right, we should not take a backup if the grain hasn't run since the last backup

22:48 <JacobWeisz[m]> I don't know if that's typical usage, but if so, any all-grain regular backup strategy is pretty wasteful.

22:49 <isd> That's true for me as well; most grains sit there and aren't run almost ever.

22:51 <isd> "On shutdown" is mostly a good strategy, except that if a server is interrupted in the middle of a backup then you lose the backup.

22:51 <isd> So you probably want it to re-try at some point.

22:51 <isd> I think a periodic job that looks for grains that haven't been backed up since their last shutdown is a good option.

22:52 <JacobWeisz[m]> That's reasonable.