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).
Description
Revisions and Commits
rP Phabricator | |||
D18143 New icons for repositories | |||
D18146 | rPbd3f441098a0 Modularize "bin/cache" purgers | ||
D18147 | rP224c4692ee0e Add a cache purger for builtin files |
Related Objects
- Mentioned In
- rPcdeba0f85b40: New icons for repositories
- Mentioned Here
- D18146: Modularize "bin/cache" purgers
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.
$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.
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?
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.