Page MenuHomePhabricator

Some means of updating builtin images without a manual purge
Closed, ResolvedPublic

Assigned To
Authored By
chad
Jun 21 2017, 12:36 PM
Referenced Files
F12345: facebook-profile.jpg
Jun 21 2017, 7:54 PM
F5010574: image.png
Jun 21 2017, 6:45 PM
Subscribers

Description

With the new repository icons I've already had another set made and am working on a new set of builtin project icons. I'd like some mechanic like celerity or whatever of updating and replacing built-in images when new ones are generated. Also not sure how to "retire" ones from Projects I don't intend to replace (low value).

Event Timeline

Also not sure how to "retire" ones from Projects I don't intend to replace (low value).

Just delete them on disk (and references to them in the code).

Any derived artifacts will be cleaned up automatically after 7 days.

This won't break anything: we never store the PHIDs of these files directly, and if we did by accident we'd notice it breaking every week when the temporary file expired.

In T12859#227762, @chad wrote:

image.png (288×1 px, 47 KB)

Is there a way to call bin/destroy F12345 from php without getting fancy?

$engine = new PhabricatorDestructionEngine();
$engine->destroyObject($file);

You need to load the object first, there's no super-shorthand that just lets you pass in a monogram.

chad renamed this task from Some means of purging/updating builtin images to Some means of updating builtin images without a manual purge.Jun 22 2017, 7:13 AM

Strictly speaking, you still have to do a "manual purge" (with bin/cache ...) after D18146, but I assume you just didn't want to have to fish around in the DB.

A slightly more aggressive fix would be to make these have a 5 second TTL in development or something (or hash the file modification time into the builtin key? But that's a bit tricky...) so you'd never have to purge the cache, but I think this arises rarely enough that it isn't too valuable.

I was wanted something I could trigger like celerity, generate a map hash or something. I presume users still need to run this command?

Oh, maybe I misunderstood. I thought you wanted an easier way to test changes in a development environment, but it sounds like you actually want end users to immediately get the new images instead of needing to wait 7 days for them?

I'm fine with 7 days, I didn't think we had any auto-update.

epriestley claimed this task.

Ah, alright. Yeah, behavior is:

  • In all cases (both development and production), new files will appear within 7 days. This was the existing behavior.
  • A user with CLI access can force new files to appear immediately with bin/cache purge --caches builtin-file. I aimed this mostly at development/testing, assuming we'd just let the 7-day cache expire on installs.