Back when this was originally reported, I'm pretty sure git lfs clone didn't exist (or at least I wasn't aware of it's existence). The appropriate fix now is probably different to the fix suggested in the original report.

I don't see this increasing storage usage - just shifting it. Right now because Phacility doesn't support LFS, all those large files are going straight into Git, which not only ends up on an EBS SSD, but also has to be cloned every single time which increases bandwidth usage. At least with LFS those costs are going to be from S3 (which I believe is cheaper than EBS SSD per GB), and bandwidth would be down as new clones no longer need to pull every version of a large file in the Git history.

Doesn't look like the repository will even attempt to clone over HTTPS:

Oh, I didn't even expect that option to be configurable on Phacility given it's a security related setting. I'll turn it on and do some speed tests next week to see if I get any measurable difference in cloning.

When you click Clone in the Phacility UI on a repository, it doesn't show any HTTPS URLs. It's possible it works if you copy the URL from the address bar, but the UI in Phacility itself doesn't give any kind of indication that it will work.

One thing I should add is that your different application tiers should be different stacks: i.e. DNS config should be one stack, web boxes another stack, DB another etc.

I can try checking if SSH compression is enabled later today (but I doubt it; I'm just using the defaults). Keep in mind the upload speed to Phacility is 8 MiB/s, it's just the download speed that's 100 KiB/s.

That's the obvious solution, but I'm not sure it's practical given Phacility's infrastructure.

It is for SSH - but compared with GitHub HTTPS it's much slower.

Final statistics are in after letting it clone overnight. Let me know if you need any more information to diagnose speed issues.

In my personal experience, CloudFormation is vastly better than Ansible/Chef/insertflavourofthemonthtoolhere. Those other tools all require some specialised syntax, meanwhile CF is just JSON and you can use the CloudFormation designer to get the JSON for any AWS resource that you're not sure how to describe with JSON.

Oh right. I mean Phacility doesn't cater to those people anyway since all repositories are private (and can't be public), so I don't think you have much to worry about there.

Well, this is a GitHub-like isn't it? In the context of what was quoted, it was specifically GitHub itself that was mentioned.

I'd personally be completely happy if all free users use GitHub forever and we only take their paying users

So our only option is to convert all our LFS objects into normal Git objects, increasing both our download times, and increasing your storage and bandwidth costs? Like our Git LFS objects for the entire repository total around 800MB, and without Git LFS, our build server will have to download that from Phacility every single time it does a build.

Is this going to be enabled in Phacility soon? We just realised that Phacility doesn't appear to have it on, and this is a major blocker for us moving from our own instance to Phacility:

I think we're going to end up trialling it with one project for now (just in case there's some prototype stuff that we're using on the self-hosted instance that we run into on Phacility), and then probably manually move other things over if we decide to pull the switch (just because we'll have done work on both at that point).

Is there any way of getting Calendar enabled on a Phacility instance? We're looking to migrate from a self-hosted instance, and it's one of the applications we use to organise meetings, etc.

Is there an import process available for customers of the Phacility free tier? We have a reasonably complex, self-hosted set up, and we're looking at Phacility but currently have no easy way of migrating the data.

I just got this email from Google Cloud:

(I preemptively set the project back to Needs Information since the followup didn't involve reproduction of the issue on a valid install)

Upstream doesn't support Phabricator installed via third-party images (including Bitnami). You need to reproduce the issue on either a blank Phacility test instance, or by following the Installation Guide and reproducing it there providing it's not an environment issue.

This issue is now fixed in the Docker image, which now uses an older version of Git and checks to ensure that it does not install 2.11 when the image is being prepared. If you're affected by this issue, run docker pull hachque/phabricator.

Separately I managed to grab this output from top at an impacted time, but this looks to be a different issue now since the CPU time is being reported against the taskmasters themselves:

For users of the Docker container, there is now a workaround available (enabled by default), which ensures that Git processes are automatically killed if the CPU wait averages above 50% in the last minute. The commit that enables this functionality is available to view here: https://github.com/hach-que-docker/phabricator/commit/0e77c36f694605371e85d420c4aecfbd3023ec5a

I think it makes more sense to have events inherit their policy from the import that created them (if they are imported events)? i.e. rather than copy policy settings on import, make the policy pull from the import similar to other systems (like how "build target" view policy is pulled from the "build" view policy).

But yeah, it is 100% not good to show this:

Okay, so I ended up having to restart my Phabricator instance to get the import to stop, then "Delete Imported Events" seemed to work right even though it took a reasonably long time to complete from the web UI (I feel like it should really be using the bulk operation infrastructure).

Oh god it's still importing even after I disabled the import and deleted events.

Just my 2c, but we've seen "table needs repair" on such a regular interval over the past 2-3 years of using Phabricator that our startup script includes a call to MySQL to automatically run "REPAIR TABLE" on startup. It's actually part of the Docker image because a broken MyISAM table will prevent bin/storage upgrade from running:

Pretty sure it was copy pasted from something else at the time; I don't believe I would have actually picked a glyph.

(comment posted twice for some reason)

I thought I'd throw our use case in here in case it helps:

Are you requesting authorisation against user PHIDs?

@epriestley in that post you linked there's a comment:

Oh, so for the hell of it I tried using the cookie data (it's in a username=token format) as the basic HTTP authentication credentials, and it appears to work! I have no idea why Google tries to get you to set up cookies when basic HTTP authentication works just fine.... :/

There isn't really an alternative technology choice here however - not only does AWS not have an equivalent service integration of this functionality, but using AWS for this would require using EC2 for compute, which would drastically increase (e.g. double costs) elsewhere. Azure is a pile of junk in my experience, which is why I'm avoiding that service as well.

I have no idea what the technical reasons are for Google's implementation to be like this. I don't have a support contract with them (they start at US$200 a month), so I have no way of asking for them to do something different. The options for setting up a repository in their system looks like this:

This would be a usability loss for us though - frequently one of the issues we have with Phriction emails is that they take you to the comparison instead of the wiki page (usually because of how Google Mail hides duplicate content). Changing the behaviour of Maniphest to do that as well would make our lives more difficult.

Will most likely be landing this Tuesday AEST unless someone else wants to land it for me.

Other users at my work experience this (i.e. about 40 or so developers run into this on a regular basis). It's an issue which is particularly bad on Windows. I think it's bad because process startup / shutdown is much more expensive on Windows than it is on Linux, which means "git status" runs for a lot longer.

@yelirekim She, not he.

As a thought, it might be nice if Administrators could pin other items to the menu bar, not just Repositories and Projects. For us, it'd be nice to pin a "Developer Enchiridion" wiki page to the menu bar.

(Though I really like the sidebar menu with projects / repositories / create new)

• Be more surgical

FYI the logo in the design / mock doesn't really look like an eye - it makes me think of a gear not an eye with a gear.

At this time if you want to use Phabricator with Windows development, you pretty much have to be prepared to have some support resources and patches internally because Windows isn't a platform that the upstream frequently uses.

Users don't have anything to do with Phragment? Unless I'm misunderstanding something?

Phragment is super out of date and FYI, hasn't seen any usage from me for a while. I don't know if anyone else is using it, but you can probably feel free to just delete the whole thing since it's a prototype anyway.

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