To summarize discussion from elsewhere: it isn't clear to me when this is better than other tools -- including arc browse D123, which already exists.

Thanks for the extra context!

reopening due to additional details

Let me add some more detailed and specific information. We wrote (and released) https://github.com/Gandi/hubot-phabs

Got it. Another quick comment: arc branch unfortunately does not work well for the HEAD~ workflow.

See T11343 for discussion of automatic "Depends On" detection. Briefly: desirable, but also complicated in the general case.

Thanks for the explanations. I can appreciate the complexity and the multitudes of workflows which I am certainly not thinking of.

That explains it then; I'm not used to being complimented about my eyesight :P

Clearly we should have a Services starting with "CloudF..." header.

I'm using CloudFront. That explains why I ignored the note, though; it
doesn't apply to me!

Please read Contributing Feature Requests carefully before filing feature requests. In particular, we need you to describe a root problem (see Describing Root Problems).

@jonah214 said he's using CloudFront (AWS) while that note is about CloudFlare (an unrelated product/company with a nearly identical name) so I'm suspicious there may be more to this than meets the eye (or maybe CloudFront was a typo).

I think we owe @avivey another lunch at this pace. Such eyesight!

I added you to Community, so you should have sweeping janitorial powers now.

I must have missed what @avivey pointed out. Thanks! Sorry to bother you guys.

Did you see the note in https://secure.phabricator.com/book/phabricator/article/configuring_file_domain/#approach-cloudflare ?

I can't reproduce this. Here's what I did:

I'm curious, is there any other way to trigger Herald to process a Differential review *other* than uploading a new diff?

Yes! Thank you.. that's it, closing this question.

In T4181#133830, @kaismh wrote:

I have created an upstart service for Ubuntu 14.04 LTS. Create a file /etc/init/phd.conf and save the following:

I was not able to use this script in any of my installations, it always causes bootup/shutdown to hang and does not properly start the phd daemons. For some reason, phd for me has been very difficult to get up and running with upstart scripts. Whatever I do, calling service phd start always results in just a hang. If anyone has any insight into how I can do this, would be greatly appreciated. I'm running Ubuntu.

Yes, nothing is in the transcript, in other words, no job was triggered

I won't comment on the specifics, but have you looked at the herald transcript? I normally find the answer hiding in there.

For example, this is what it looks like on our instance:

no.. they've been a part of that project since the beginning

If you're not allowed to see PHID-PROJ-rwnekrajar5m6diprobx, it will not be returned from project.query. Herald should be seeing all projects though, so PHID-PROJ-quo7cpreceuh6hnor3pw missing is strange.

yes... they're secret :)

Is there anything special about the projects PHID-PROJ-rwnekrajar5m6diprobx and PHID-PROJ-quo7cpreceuh6hnor3pw? Is any of them secret?

I have had users request this as well and we actually have a custom application that makes use of this. When you do this you run into other problems such as harbormaster doesn't clean up after tasks. That becomes the job of Drydock and you will have to write your own drydock blueprint to do this in any kind of sane way.

I imagine this task is easier now that we have a "Move on Workboard" selector.

Thanks for the response, it does seem D15958 is what I am looking for.

In T5024#59425, @epriestley wrote:

For the first case, maybe a column permalink would be a better solution? Then you could navigate back up the board easily. We can structure this as a search query instead (and it might not be bad to make that possible, for Dashboard panels) but it will lose some context. There's also no control which will easily let you select a column right now, and building a nice one is probably a fair bit of work (plus, it overlaps a lot with some other less well-defined tasks and infrastructure-blocked things).

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

svn is used today. It never used before. So, I not sure whether it can work before. My install is out of date, this means need to update phabricator?

I think the root problem here is that "Herald added a subscriber: $user" is seen as email-spammy yet people are unwilling to edit their preferences to disable notifications for subscription-changes.

Does the error occur after you update Phabricator? Your install is out of date.

This doesn't appear to be a valid bug report. You must update Phabricator before filing a bug report (your logs indicate you are a month behind), and you must provide steps we can reproduce the bug.

Though I don't completely understand the specifics, I do have this issue resolved.

#1146: Table 'phabricator_metamta.metamta_mailinglist' doesn't exist

is an error from MySQL, and not from Phabricator. I believe the problem started when I restored the database from a backup. Rather that using a dump/restore, I rolled back to a previous filesystem snapshot on my database server. That filesystem snapshot contained :

mysql/phabricator_metamta/metamta_mailinglist.frm	
mysql/phabricator_metamta/metamta_mailinglist.ibd

database files. That particular table, however, no longer exists in the current versions of Phabricator. Once I removed those two files from the database server and restarted the MySQL server, the bin/storage upgrade command worked without error.

Awesome, thanks @epriestley. The update cron script runs that bin/storage upgrade every time.

Note that you need to bin/storage upgrade after picking up D16312 for this change to take effect. You should normally be doing this anyway, just mentioning it since it's not obvious that this would require database adjustments.

I think arc actually calls differential.getcommitmessage and then passes the result right back to differential.parsecommitmessage to split it into fields. That could/should work differently than it does.