Moving to a sandbox instance.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 15 2016
Moving to a sandbox instance.
Moving to a sandbox SAAS instance.
Moving this to a SAAS sandbox instance.
This isn't a valid bug report (for example, it is missing reproduction instructions). Please see Contributing Bug Reports for help writing bug reports we can accept upstream.
Tested. master branch working . thanks.
Dec 14 2016
(the revision number is in ` because I got an exception trying to attach the mention, I guess)
If triggers (described in T5474) would not solve your problem, feel free to file a new feature request describing your problem (see Contributing Feature Requests, Describing Root Problems) and we can discuss approaches.
I think when one searches for something, or filters by something, that something does not need to have a "special meaning". Searching for "sandwich" does not require Phabricator to know or care what a "sandwich" is.
I think the major intent was being able to edit "View Policy" so you could create private documentation, but I don't recall if we got that far.
You could tag a project I think, but not sure what that actually did.
Basically nobody is using Diviner, and I don't think the "Edit Book" page actually does anything useful.
I think this is actually for the primary task lists, I just didn't do a good job of describing it. Here are more specific reproduction instructions:
@joshuaspence: Did 'per column scrolling' fix this issue? Asking as I have not experienced this problem in Firefox lately...
I believe this is fixed in HEAD of master now. Let us know if you're still seeing issues after upgrading.
Broadly, DifferentialCustomField drives a very large amount of stuff in Differential. This was the first generation of custom fields, and is the most complex implementation.
oh, sorry. i saw it as " I had fix it a few hours before..."
Oh, sorry, maybe you misread? I said "I think I'll have it fixed in a few hours", meaning that I don't expect it to be fixed until later today. Unless you can pull changes from the future, it won't work yet. I'll update this task once things are fixed.
No, sir. i just upgrade to latest git commits. still can not do it.
This is related to changes in T11114. I think I'll have it fixed in a few hours.
We're OK with bringing custom build steps for popular platforms upstream, like HarbormasterCircleCIBuildStepImplementation for CircleCI.
Using arc diff is ok. but using the web form is not working at all
FWIW: Travis is working on a build.run API: https://docs.travis-ci.com/user/triggering-builds
In T10038#203547, @cspeckmim wrote:@rscircus - this task (like I assume most tasks here) needs paid prioritization to move forward. see https://secure.phabricator.com/w/prioritization/
Oh really? Nice to hear, that I'll get monetary appreciation for contributing. 😉
Dec 13 2016
I think this is fixed now -- let us know if you're still seeing issues. Thanks for the very thorough report!
Using Chrome's network tab + disable cache, loading a page from the effected system shows that some rsrc requests take 55s each, during which chrome is "loading". Since they're static resources, I guess it's hard to notice when cache is on. Also, I don't think secure-dot is effected.
I wasn't able to reproduce any hangs or bad behavior from curl locally, but I think D17045 should cause us to select either compression or Content-Length, which is a reasonable thing to expect us to do.
I can see this too with an unknown version of Apache (Probably 2.2.15) over HTTPS, PHP 5.3.3 (built: Aug 11 2016 17:13:57) (w/o explicitly setting the header) :
curl -v 'https://..../res/defaultX/phabricator/e18bf0da/core.pkg.css' --compressed > /dev/null ... curl: (18) transfer closed with 170238 bytes remaining to read
You could also ask Travis for a build.run sort of API. If you're a paying customer of theirs, it might be easier for them to prioritize this request than it is for us to prioritize Travis support. With such an API, there's a fairly straightforward path to Phabricator upstream support.
You could also ask Travis for a build.run sort of API. If you're a paying customer of theirs, it might be easier for them to prioritize this request than it is for us to prioritize Travis support. With such an API, there's a fairly straightforward path to Phabricator upstream support.
If Harbormaster does not trigger the build, this system may race (Travis may complete a build before Harbormaster generates a target).
I consider this negligible -- Travis build takes at least a minute, because of machine startup times. I've never seen Harbormaster generating the targert taking over a minute.
FWIW, the API seems not intuitive for me: why does the user is able to set arbitrary properties via Conduit, if there is no way to get them back? Is exposing the API actually a hack, to achieve other goals?
Okay, thanks!
Oh, I think the issue is this:
I also can't reproduce this:
It's fine to consider it not a bug. Mainly I wanted to provide the info that it doesn't work for documentation purposes, in case anyone else runs into the same situation in the future. (We ran into this by trying to transition from a very old Phabricator installation to a new one with hosted repos, but with a legacy deployment setup that needs a non-bare repo copy, and didn't realize that Phabricator didn't fully support hosted non-bare repos.)
Why do you consider this to be a bug, then?
Do you consider this ticket just "make arc patch restore all local commits", or something more?
No.
Now I'm even more confused. This ticket still doesn't conform to modern Feature Requests rules :)
Oh, that's actually a different task, I don't currently plan to implement that. Let me me rename this to be more clear...
Do we tell you to do this in the documentation anywhere?
This is now better tracked in followups: