In retrospect, I should have rigged the hash for the the "Remove libphutil" commit to have some cool recognizable prefix like de1e7ed, since half of arcanist/ now ends up there on git blame.

Also, guess what this checkbox does on Windows 10?

Consider this script:

This was almost certainly resolved by D16273.

No clue how to reproduce this.

I believe this is essentially just T13209.

Changes in T13209 make this the only mode.

D11688 implemented this.

...we currently can not suspend instances through the web UI. The non-hacky way to fix this...

I think I'm done for the night, but we're down to 18 failing tests under Windows.

PHP7 introduces random_bytes(), which is a more accessible pseudorandom source on Windows than the other sources we use.

ArcanistLinterTestCase->lintFile() has a bug where it does this:

A lot of tests fail on Windows if core.autocrlf is set to convert "\n" line endings to "\r\n" line endings on checkout, which is the default behavior. In theory, this is fixable, but I'm not sure it's really worthwhile. At the least, I first want to get things passing without dealing with these tests.

Evolved into T13209.

It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.

On startup on Windows, arc currently complains that cURL isn't enabled. It gives you some okay-ish instructions for enabling it.

I'm currently trying to update my Surface Pro so I can look at making arc unit in the wilds branch pass on Windows. I've restarted to install more updates about 5 times, am currently stuck at "Feature update to Windows 10, version 1803 - Downloading - 0%" which appears to just be not working.

There should be no code anywhere in Phabricator to delete saved queries. The expectation is that they are never deleted or garbage collected because they may have been embedded in other pages, sent via email, etc., and deleting a saved query will break any use of the link in a permanent/external context. The table is expected to grow without bound, although at a slow enough rate that it does not create a maintainability issue.

In T13208#241647, @epriestley wrote:

[..] the issue is actually with persisting the query in the first place, not deleting it?

Could it be that a user assigns it to one of their "personal" custom queries and then later they delete that query by way of the maniphest saved query ui?

I'm not sure what's caused this either but I've seen it twice on wikimedia's production install.

welcome back little comment border :) you have been missed

I cut the Week 39 release with that stuff and am deploying it to secure now. I'm going to send it to repo006 if that goes cleanly to deal with PHI894.

My expectation is that no upstream code exists to ever delete saved queries. My guess is that either:

"Use the API" seemed to work OK. Of those instances, only bastion005 is at all unusual.

I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests

begins to provide for this

D19706 begins to provide for this. I'm just going to roll the rest of it into T13098 since most further changes are likely to be entangled.

The lint unit tests are significantly entangled with general lint infrastructure, so I'm now looking at making arc lint run again: I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests, so we don't end up with a narrowly-scoped fix to the lint tests that needs to be rewritten once arc lint comes online. In particular, linters currently have their hands very deep in repository / working copy information. Although I think it is plausible that a linter may want access to this information (for example, we have a unit test method which reads configuration to render a link to the Phabricator install, which doesn't seem strictly bad), I think linters and unit tests should not require this information and we should not need to build an entire working copy to run a linter.