Thanks, that's much more clear than the original description!

No they're not. I know it's a tiny difference, but look at this closely (left is my proposal, right is the current state):

(I think D18132 should fix this once someone gets a chance to look at it.)

I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):

This should now be fixed in HEAD of master, and promote to stable within about 12 hours. Thanks for the report! Let us know if you run into anything else.

I’m fine waiting for the fix. Thanks @epriestley

A related issue surfaced recently. Actual use case (forensically reconstructed):

Oh, this is actually the Mercurial flavor of this action. We have this one in the Git flavor, which is why I was surprised:

My expectation is that this action can never appear -- this is the pre-Drydock hacky temporary action -- so something troubling is afoot.

See also T10005 (bulk editors for all applications) and T6722.

I think a minimal reproduction case which is typical of this example is:

Looks to be just the presence of the "?" in the text

"XXX://123456 XXX XXX XXX://123456 XXX XXX"

You and me both. I am super confused.

Well the stack trace says PhabricatorYoutubeRemarkupRule, so I'm confused what the issue is.

LOL @chad Literally reproduced this issue here by trying to paste the above line without the back ticks. It refuses to let me comment.

I'm not sure how without giving you the entire commit message which I cannot. I think key would be a having a commit with a line (probably the first one) that looks like this "XXX://123456 XXX XXX XXX? XXX://123456 XXX XXX XXX"

How can we reproduce this issue locally?

There also seems like there may be an issue with the current parsing logic since the "detected URI" has spaces which I do not think are valid in a uri and it should have been detected as two separate URI's with some stuff in the middle.

The URI that is ambiguous is a URI to a company App on MacOS. The only part of the URI that matters is the xxx://123456. The rest is just the title of the item referenced by this URI and this title contains a "?" which mixed with T12526 may be causing this issue. There may also be a place you now need to catch exceptions thanks to URI parsing logic changes. Just guessing here from what I can tell in the code.

Yes ,Emails are not always sent ?This is one of the problems.

You probably don't want to put much value in advice from passing Internet strangers, but... Having used Ansible for configuration management for a while, it certainly has a "worse is better" feeling to it. You folks seem like you might be more of a "better is better" outfit. Contrast, for example, your approach to upstreaming user-written linters versus their approach to upstreaming user-written modules.

Ah, alright. Yeah, behavior is:

This is great for testing!

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

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 was wanted something I could trigger like celerity, generate a map hash or something. I presume users still need to run this command?

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.

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.

No problem, without knowing how to reproduce an issue or see it locally, we can't really move forward here. Will close out and if it comes up again with another user and reproduction steps, we can re-visit. Thanks!

Sorry Chad,

See Contributing Bug Reports, specifically we need a full set of steps the upstream can reproduce to see the issue locally. I've installed Phabricator dozens of times on various platforms and never needed this command.

So simple

In T12859#227762, @chad wrote:

I think we should have our crontabs in version control regardless of whether or not we add tmpreaper to them, so I'll make a task for that.

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

Just to clarify, Phacility is the paid hosted version of Phabricator. If you installed Phabricator locally, we cannot help you with this request via Phacility. You'll need to follow Support Resources for your self-hosted installation.

If you want to move forward with that:

Great! Please mail support at support@phacility.com and identify which instance you're paying us for, then we're happy to help you. We won't help you here, since this isn't the right way for customers to get support.

This should do the trick. It runs off atime by default. We could just set the time period to several days if we wanted to. Alternatively, if the filenames for extremely long-running jobs are predictable, there's a --protect '<shell_pattern>' argument we could use to avoid cleaning up those files.

Every repo host is equally affected, so I'd like to deploy crontabs as part of the regular deployment process if we use them as part of the approach here. That would require first codifying a handful of custom crontabs, including one on secure which regenerates documentation daily on only one host. This codification should happen anyway eventually, but it's a little bit of work, and wasted effort if we're switching to Chef/Salt/Ansible/etc soon anyway.

Yes,we are Phacility customer And I deployed it on a Ubuntu server,Thank you.

Should we just add a crontab entry to clean /tmp to paper this over until we get it fixed for real?

If you're a Phacility customer, please mail support at support@phacility.com (and identify your instance).

Why is git diff --no-index being used instead of and diff, and why is --no-prefix being used?

@epriestley git diff --no-index --no-prefix -U2000 $old_file_path $new_file_path