I think these users are just giving up immediately.

My only random thought is if email auth is open and the install is public, not sending email until you've been approved. This is mainly an Open Source host issue.

Isn't Phabricator entirely PHP? What is there to build?

EC2 spot instances are only terminated if the market price exceeds the bid price. If your bid price is the price of a normal non-spot EC2 instance, then it's rare to have instances terminated, as the only time that occurs is if someone is paying more for spot instances than non-spot instances, or if someone consumes all of the available EC2 instances of that instance type.

this is better

Keep in mind you also can't rely on resources existing until Drydock closes them; systems such as EC2 provide no such guarentees for machines (and spot instances you should expect this to be the case).

By having artifacts only exist for the life of the build, you end up designing build processes which need permanent "artifacts" to push and pull those artifacts to an external storage system such as S3. The storage costs of S3 are much cheaper than keeping an EC2 instance online.

In D13421#150566, @epriestley wrote:

(under certain, unknown conditions).

I don't want to upstream this kind of stuff.

My main concern with retention policies on build failures is that it will increase costs when there are Drydock resources being held open by artifact leases on services which cost money (such as EC2).

You would be better off setting up the linters / unit tests through arc, and then making gradle run arc lint and arc unit as part of it's process.

The web UI shows that X() exists!

Phabricator doesn't use Javascript pagination; the links to the next set of results are just standard HTML links / buttons: https://secure.phabricator.com/maniphest/?after=8838

I would imagine either a type ahead or a text box to enter the name of an icon that isn't one of the standard 16.

Is there any reason not to completely remove the Maniphest reporting charts? I don't think anyone finds them useful and as per this task, they're confusing to anyone who doesn't know their history.

is even better for the fire fighting badge :3

I mean, just look at how pretty these are with their icons (I set these via SQL updates):

I would also be fine with some way of running iconv on a file before it gets passed into Arcanist; this could be done as a separate linter but would require the multi-pass linter stuff so that after fixing it up with iconv it could then be processed by the C# linter.

I don't believe there's a way to convert the offsets on the C# side of things; the offsets returned from the external linter are from the compiler API. When I read the UTF8 encoded file as ASCII in C# (so that everything is byte-based), and pass the resulting text into the compiler API, it then can't parse the file because the UTF8 bytes mangle the source code.

It'd be nice to also have a note as to why the badge was awarded (and not just who awarded it + date)

better make the next one good

Replicating right now:

Oh hm, I didn't consider two different linters suggesting similar patches; I was just considering the scenario of the same linter raising similar patches.

When the patches are the same I'd expect this to be considered a flaw in the linter; there should never be two suggested patches which yield a result of the same importance.

I'd expect the change that wholly encompasses the other to take precedence. For example a patch removing characters 20 characters at offset 10 should take precedence over a patch that adds 5 characters at offset 15.

I've temporarily worked around this by making it remove from the start of Debug.Log, but this means that the line itself doesn't get removed (the indentation policy adds indentation to a line which then has all the contents after that removed).

I tested running the lint policies in the opposite order, and it didn't make a difference to the suggested patch.

Oh okay, it only works in some apps, and doesn't show in the Remarkup / comment preview either yet :P

Testing? o_o

I also think the Conpherence mobile web app is pretty reasonable, it just needs push notifications to get people to come back to it. Building a native app is something that can be done way down the road, while push notifications for Conpherence is something that can be done shorter term to make Conpherence useful now.

Oh no, I definitely wouldn't want push notifications for all of Phabricator either; that would defeat the purpose of having a separate channel for high frequency messaging. I just want them for Conpherence :P

Yeah I've been getting this recently too.

I never want to get emails for Conpherence, unless they're summary messages of conversations that I haven't already read, regardless of T7004. I do want to get immediate notifications on my phone for conversations that are happening, I just don't want it to litter my inbox.

Push Notifications are far more suitable for Conpherence where sending emails is extremely spammy (especially because emails are either always sent or never sent). Push notifications would allow you to bundle multiple messages into a single notification like Slack does.

Generally we find that the commit / message parser tasks tend to get done first, and take up taskmasters that could be processing Harbormaster builds. This delays builds because we have less taskmasters available.

@epriestley Is there an ETA on this? It's been 7 days since I cleared out failing Git parser tasks and there's another 20 I need to clear out now. This issue has a significant impact on our background processing because commits without UTF8 data in them effectively block the queue.

The discovery map is something that looks like this:

Okay thanks

@epriestley that custom policy was intentionally set as the screenshots contain the names of people who may not want them on the internet (plus other event details and whatnot)

You mean you'd rather have a build step you add to a build plan that skips the rest of the build targets?

If it were failing, you'd need to go and remove all the build steps that call the disabled build plan. The scenario that this issue was raised in is that a team wanted to temporarily not deploy to one datacenter, so they disabled the build plan for that datacenter.

Invalid utf8 for JSON encoding. Basically until phabricator has a binary wire format for conduit that can handle invalid character sets, these commits will always fail.

Why would you not just add arc to your PATH? That can be either done through the UI, or permanently via Powershell:

The problem is that escaping commands on Windows is thoroughly broken; there is no one solution that will work universally for everyone. Fixing this issue by changing the escaping so that it works under Command Prompt may well break it under msysGit, and it's important to understand in what situations the error occurs so that we don't cause regressions for anyone else.

Can you try running Arcanist commands under msysGit?

We used the above script to install Arcanist this Friday (2 days ago). If you are running a version near that date or before it, then it's definitely an environment issue as the script works fine.

For reference, this is the Powershell script we use to install Arcanist on developer machines (replace the URL https://code.redpointsoftware.com.au/ with your own instance). On a fresh install of Windows (or an install of Windows that does not have PHP or Arcanist installed), run this under an Administrator Powershell prompt and restart the computer.

I don't understand where these issues are coming from; we have several developers that use the latest version of Arcanist and libphutil on Windows without issue.

Fix bugs

Fix issues

Fix issues with calculation of sleep time

I didn't like that they were too large and that the building icon rotated. I think we could probably do with just:

The issue is here as well in Differential, just less noticeable:

The UI is the standard search UI though (with status icons).

It's a custom application (for release management).

User got this:

Upgrading server version of Arcanist didn't fix it; waiting to hear back from users whether or not upgrading client Arcanist fixes it.

Fix drive path access