This is T4863.

I'm unable to get URL shortening to work locally. Is there some apache configuration required to get it working?

Its seems that when i am pressing run build from the web interface it gets stuck in the building part while if i execute

@chad Could be. I wasted a whole day on this. Anyways i moved to ubuntu now and it seems to be working pretty well there.

Giving full access to all users for the host repo folder solved the issue. As this is a vulnerability, I shouldn't left it as 'chmod a+w'.

I have the same problem.

difficult? right?

Maybe T4947: SELinux / AppArmor ruin everything all the time?

Just to be sure i reinstalled the whole thing in a new machine(Centos 7), but was still getting this issue. I switched to ubuntu and it works fine for me. I followed this one as well but still din't make it to work. https://blogs.gnome.org/aklapper/2014/11/10/phabricator-on-fedora-20/

I think it's just adding implements PhabricatorApplicationTransactionInterface, then adding the methods for that.

I poked at it, but wasn't immediately obvious. I can poke again tomorrow.

Also to fix.

I think this is straightforward to fi.

Sorry, we don't offer help with third-party application development!

Probably not. Because it's a scalability issue this does get some amount of internal priority, but we have a large amount of external prioritized work in queue ahead of it (see Prioritized).

Not yet, but soon. New code should use project.edit.

Did the project.create API deprecated?

T10423 was resolved indirectly (in connection with T11524) so we've sort of inched forward here.

Try using project.edit instead.

I'd like to sort out T9365 / T10635 (better aggregation and/or query options for unit/coverage data) first, since that likely impacts how we GC this data. Ideally, we'd leave an aggregated stub behind (e.g., pass/failure count) rather than nuking the data completely.

Specifically, my plan here is:

du -sh returns 1.3GB for that repository so it should be below that limit.

GHC appears to be running into this limitation. We would prefer to use anonymous HTTP access with our build bots; is there any hope that this will be fixed in the near-term?

We can build this first, then backport it to Doorkeeper and feed.http-hooks, so this doesn't need to be an enormous mess.

Curious, Did you follow the setup guide that includes the rewrite rules? Check your apache / nginx configuration

Yes that would do it.

If we just added an action to Herald like Queue Call to Webhook: http://whatever.derp/, would that cover this? I think that's often kind-of-a-bit-hacky, but probably makes a lot of these soft use cases easier.

I'm a little wary about this. Some of my concerns:

I think this is all generally reasonable to bring upstream, at least in spirit, but I want to wait for planned arc changes (overviewed in T11429) to get a little further along and build it on top of that.

I think you should already be able to add subscribers and projects (and take some other actions) with Herald, by writing a "Global" rule using the "Receiving email address" condition. Here's an example:

Going to merge this into v2 Dashboards so if that does ever move forward, we'll have your feedback.

Thanks for the suggestion. We have no current plans to pursue this. Please use the link provided to see the full queries results.

What do you mean that stuff? normalizeInput?

This stack overflow post suggests that with apache you could use something like:

Go blame that stuff and try to figure out why it's as early as it is.

I had some family stuff come up and was only able to spend about three hours on this before Ludum Dare ended, and it never turned into anything playable. I got as far as letting you jump between systems and zoom into planetary bodies:

This is almost certainly T4369. I would expect that this repository is larger than 2GB?