I'm about to start implement full dereferencing support. Cases that are missing now:
($expr)[0]; SomeClass::BRILLIANT_CONSTANT[5];
I'm about to start implement full dereferencing support. Cases that are missing now:
($expr)[0]; SomeClass::BRILLIANT_CONSTANT[5];
Good time of day palls.
How to add tag (respectively connect repo to project) in that new style ?
I'm asking because till now all our commits to HG repo was referenced to task with keywords like "ref" or "closes" etc.
All our repos is organized and setup like that. Today I must create new repo attached to new project and the problem....
Can't reference or act to any task/project with commits?
Or I miss something but can't find even add tag command.
Please advice, thanks in advance !
OK, thanks. Because there is no documentation about what any of these choices mean would you like to make this task a documentation fixing issue?
Code being owned by a package does not tag it with a project.
So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:
@hach-que My bad, misread the title. Thanks for the clarification :)
D15977 improves some behaviors slightly and adds more extensive logging for signal handling. I don't think I caught anything with real meat to it.
@kaendfinger This task is about arc patch. arc land is separate, and I don't believe there's anything Arcanist can do (other than not signing at all) because it must mutate the commits in order to land them. Since you don't have the original author's private key when landing, it can't be signed correctly when you do arc land.
D15975 should fix the (Exception) No such daemon "39084:6ra7uz"! error. I'm not sure if it will do anything for stability or not, but it should reduce noise. I didn't uncover anything interesting in resolving it (it wasn't really even a race, just a fairly straightforward set of state management bugs).
Sure thing. I left the office shortly after posting on Ponder (hence the
answer delay).
You can talk to Passphrase over Conduit; you need to give credentials access by clicking the "Allow Conduit Access" action.
This is almost certainly not a resource problem, but I have no idea what it is.
Yes, they die when called manually.
My tentative plan here is:
I actually have no clue. There are AMIs for it in AWS but maybe that's unrelated or related in some complicated way.
Isn't CloudLinux a shared-host?
(By "provide instructions to construct a similar system", I mean something we can do in a few minutes, like launch a VM in AWS. I don't see any CloudLinux 6.8 AMIs offhand there, though.)
The recent changes to the local filestore permission did not seem to resolve this (my truck went missing again). However, now that the logs aren't totally polluted I may see the exception related to this. I'm not positive whether this provides more insight or not, though.
[25-May-2016 13:22:23 America/New_York] [2016-05-25 13:22:23] EXCEPTION: (PhutilProxyException) Permanent failure while executing Task ID 4733388. {>} (PhabricatorWorkerPermanentFailureException) Unable to load transactions: PHID-XACT-DREV-vl56ah6csf7wlan. at [<phabricator>/src/applications/transactions/worker/PhabricatorApplicationTransactionPublishWorker.php:112] [25-May-2016 13:22:23 America/New_York] arcanist(head=stable, ref.master=d54cb072facd, ref.stable=1439aaa87183), phabricator(head=stable, ref.master=7cc8a73d1efd, ref.stable=2c67d9c8ace2, custom=2), phutil(head=stable, ref.master=83f09f6c5a03, ref.stable=76425eaa8125) [25-May-2016 13:22:23 America/New_York] #0 <#2> PhabricatorApplicationTransactionPublishWorker::loadTransactions(DifferentialRevision) called at [<phabricator>/src/applications/transactions/worker/PhabricatorApplicationTransactionPublishWorker.php:19] [25-May-2016 13:22:23 America/New_York] #1 <#2> PhabricatorApplicationTransactionPublishWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:122] [25-May-2016 13:22:23 America/New_York] #2 <#2> PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php:171] [25-May-2016 13:22:23 America/New_York] #3 <#2> PhabricatorWorkerActiveTask::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php:22] [25-May-2016 13:22:23 America/New_York] #4 PhabricatorTaskmasterDaemon::run() called at [<phutil>/src/daemon/PhutilDaemon.php:183] [25-May-2016 13:22:23 America/New_York] #5 PhutilDaemon::execute() called at [<phutil>/scripts/daemon/exec/exec_daemon.php:125]
A sub-problem here is that if daemons discover commits but those commits are deleted before they can be processed, the tasks fail forever. This is normally unusual (git won't GC the commits for a few weeks, which often gives the daemons enough time to process them) but cases like fiddling with tracking, re-cloning a repository, everyone going on vacation for a couple weeks, or clustering an observed repository can exacerbate them.
For prioritization, I estimate we can complete this within 6 hours. It may all be straightforward and easier than that, but there are enough weird edge cases and UI implications that I don't want to commit to a best-case estimate.
You can test with "Discovery" at https://phabricator.wikimedia.org/
Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:
Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).
The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:
I can remember trying to file a bug against Safari when I worked at Apple, seems like a simple task. But typing "Safari" came back with 50-100 tags... I had no clue as a first time filer what to fill out. A short description might have helped, perhaps. But overall I guess I'd like to understand what users are ending up at the browse dialog to begin with. In the Safari case, having something like Nuance is better for the novice user than asking them to wade through 50 results and guess the correct one. I want to basically make sure we understand which user we're helping here.
I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.
@witrin your implementation is really useful. Just an addition for custom fields of storage type PhabricatorStandardCustomFieldSelect (dropdowns). The getValueForStorage() function only returns the index of the field's value.. I found this useful in getting the human readable format of the field's value
(Although we do formally support and have documentation for the the "import, then make hosted" and "copy the whole working directory into place" methods of repository import now, both of which skip the pre-receive rules.)
Disabling Herald there only disables the post-push, at-discovery-time rules, not the pre-push pre-receive-commit-hook rules.
Hasn't this been done for a long time? In the current form on the page diffusion/edit/.../page/actions/ ?
I worry overall that this will compound the issue when installs have too many projects. That is, if they already have hundreds/thousands of projects, doubling the information makes the UI twice as large and difficult to navigate through. Maybe one idea would be to only show additional information optionally (via a checkbox) or only after results start to get filtered?
My plan is to put an on-hover (always available on mobile) edit icon on top of the thumbs on the edit UI, similar to how the interaction works on workboard cards:
hmm. I'll close this since everything seems to be working as intended...
Even more interesting, that code works fine on my instance...
Interesting. test_generating_toc has a TOC,
This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.
Can you create a document on this install which you believe should have a table of contents but doesn't?
This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.
Thanks for getting back to me so quickly @epriestley!
Copying in some context from elsewhere:
This is conceptually reasonable, but likely years away. We ship no native code right now. Although there are many Phabricator applications which could take advantage of an optional OS client (for example, to make it easier to upload screenshots or access files) the pathway from where we are now to building one is a very long one, and none of these use cases are near the top of our priority list.
Please read Contributing Bug Reports carefully and make sure you provide all the required information, particularly reproduction steps (see Providing Reproduction Steps). Thanks!
It should probably go under T10978, I believe. I imagine it would get it for free, but worth mentioning over there nonetheless.
I thought I tried that too, but perhaps I'm confused between differential and diffusion (such very confusing terminology for people new to phabricator!). I'm making inline comments against the commits, not against code reviews.
This task is for inline comments on a diff in Differential.