It doesn't make sense for "Lease Working Copy" to not provide a working copy.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 21 2015
You can probably set it to "0" to achieve the same effect, but this is a bug and I can reproduce it locally.
This will be available in a future repository.search method, via T7715. See here for some discussion:
This is far outside even the far-future scope of Harbormaster.
I thought that it should still work because I'm running the repository pull daemon on the worker host?
Sure, I get that... But the import is failing even on the instance running without the --no-discovery flag.
In T9905#150315, @nicolast wrote:I lost the preview (after a code update) while creating a new task on Maniphest. I it possible to restore it?
I don't think that would fix the deadlock issue, which seems to be the root cause?
D14846 should fix the package case, but I'm going to leave this open for followup work: Files, Pastes, Maniphest should get indexes; and we should replace the powerful systems in Projects and People.
As general infrastructure cleanup, I would like to split the existing SearchEngine and DestructionEngine components apart...
As part of this cleanup, we should also fix T9890.
Why do these plans need to run sequentially in the first place?
Seeing this on the repository host:
Nevermind, this was my fault... the webserver was running a different version of the codebase than the rest of the cluster.
Nevermind, this was my fault... the webserver was running a different version of the codebase than the rest of the cluster.
{ "error": null, "errorMessage": null, "response": [ { "activeDiffPHID": "PHID-DIFF-jljg7seerlxdwpqmctef", "authorPHID": "PHID-USER-abzwhc667osh5mwd4gk7", "auxiliary": { "jira.issues": [], "phabricator:depends-on": [ "PHID-DREV-2qrid2heomsyqknvz6ig" ], "phabricator:projects": [] }, "branch": "master", "ccs": [], "commits": [], "dateCreated": "1450064608", "dateModified": "1450349113", "diffs": [ "590952", "590180", "589937" ], "hashes": [ [ "gtcm", "77b01130662887c1a7b5b15a6c04ddf0aa63820d" ], [ "gttr", "bb2e97dcd67904e02fea4ac9643b6467f48aa6af" ] ], "id": "29252", "lineCount": "567", "phid": "PHID-DREV-7cs76mhttnhp7homxd4l", "repositoryPHID": "PHID-REPO-e7qvu3z7a3uhk7akjy7y", "reviewers": [ "PHID-PROJ-cbz6xwpsmzwa4oqodzqg", "PHID-USER-5vh6hvh4jprplkbupz7g" ], "sourcePath": "/home/josh/workspace/REDACTED/", "status": "0", "statusName": "Needs Review", "summary": "REDACTED", "testPlan": "`arc lint --everything`", "title": "REDACTED", "uri": "https://phabricator.redacted.com/D29252" } ] }
> arc amend --trace libphutil loaded from '/usr/src/libphutil/src'. arcanist loaded from '/usr/src/arcanist/src'. Config: Reading user configuration file "/home/josh/.arcrc"... Config: Did not find system configuration at "/etc/arcconfig". Working Copy: Reading .arcconfig from "/home/josh/workspace/REDACTED/.arcconfig". Working Copy: Path "/home/josh/workspace/REDACTED" is part of `git` working copy "/home/josh/workspace/REDACTED". Working Copy: Project root is at "/home/josh/workspace/REDACTED". Config: Did not find local configuration at "/home/josh/workspace/REDACTED/.git/arc/config". Loading phutil library from '/home/josh/workspace/REDACTED/support/flarc/src'... >>> [0] <conduit> user.whoami() <bytes = 117> >>> [1] <http> https://phabricator.redacted.com/api/user.whoami <<< [1] <http> 2,570,538 us <<< [0] <conduit> 2,572,524 us >>> [2] <exec> $ git diff --no-ext-diff --no-textconv --raw 'HEAD' -- >>> [3] <exec> $ git ls-files --others --exclude-standard <<< [2] <exec> 309,152 us <<< [3] <exec> 442,695 us >>> [4] <exec> $ git diff-files --name-only <<< [4] <exec> 161,257 us >>> [5] <exec> $ git rev-parse --verify HEAD^ <<< [5] <exec> 17,530 us >>> [6] <exec> $ git rev-parse 'HEAD' <<< [6] <exec> 22,073 us >>> [7] <exec> $ git log --first-parent --format=medium 'HEAD^'..'d83b73a78e5ffea324c3948866988112837f342b' <<< [7] <exec> 5,918 us >>> [8] <conduit> differential.query() <bytes = 177> >>> [9] <http> https://phabricator.redacted.com/api/differential.query <<< [9] <http> 623,208 us <<< [8] <conduit> 623,581 us >>> [10] <conduit> differential.getcommitmessage() <bytes = 166> >>> [11] <http> https://phabricator.redacted.com/api/differential.getcommitmessage <<< [11] <http> 727,894 us <<< [10] <conduit> 728,127 us >>> [12] <conduit> differential.query() <bytes = 143> >>> [13] <http> https://phabricator.redacted.com/api/differential.query <<< [13] <http> 578,351 us <<< [12] <conduit> 578,568 us Amending commit message to reflect revision D29252: REDACTED. >>> [14] <exec> $ git commit --amend --allow-empty -F '/tmp/e8ccn3ifj3wc8cko/13791-sHgYHg' <<< [14] <exec> 203,644 us
The exception is correct in that the reviewers field contains garbage:
Dec 20 2015
Use spaces, a positive "open source" project or custom field, make "Games Project" public, or use a public negative project which is a companion to "Games Project" (Herald rules could enforce that it was added when "Games Project" was added and removed when "Games Project" was removed).
This is expected. Queries using projects you do not have permission to see are not valid, and do not return results.
I don't think it's helpful for the withMemberPHIDs() case. Here's a specific example:
Quote shell arguments which contain spaces or special characters. This flag behaves just like git commit -m ..., svn commit -m ..., and hg commit -m ..., and the quoting rules are the same shell rules used by every other shell program.
See also T5267. I found that task by searching for "translatewiki" in the global search.
Dec 19 2015
This is the current intended behavior.
A technical issue I'm running into is that there is pretty much no realistic way to implement $project_query->withMemberPHIDs(...) unless we already have a computed view of effective memberships.
The plan in T3670#149755 has one potentially odd implication: if implemented naively, you may not be able to see all the members of a project.
We haven't seen more of these for a few months and I've been more consistent about tidying them up so I'm just going to close this out, but let us know if anyone catches more of these.
I've updated the description, but I currently expect to promote these changes next week.
Dec 18 2015
@nickz I believe both issues are now fixed at HEAD. Let me know if you run into anything else.
Okay. You can implement the behavior you want like this:
I would expect 4 of the builds to fail as they can't allocate more resources.
There's no technical reason for that, either, although it probably doesn't make sense to raise it in advance of just fixing this properly.
How would you propose Drydock detect that it should fail if the situation is a legitimate deadlock that can not be alleviated by cleaning up resources?
So you'd suggest that we encourage Drydock users to configure limits in excess of available resources ("not wear a seatbelt") to improve error behavior when they configure a deadlock ("fall in the ocean")? If so, wouldn't it be better to simply remove the limits entirely ("uninstall seatbelts from cars") so that they can't accidentally configure a limit with bad behavior?
I've reproduced the first issue with the lease breaking but not being released. Here's what I did:
If you drive without a seatbelt, it will be easier to escape from your vehicle when it becomes submerged in the ocean.
For example, suppose we have perfect resource reclamation and reuse algorithms which always instantly destroy a resource the moment it is no longer in use.
The recommended solution for T9875 is to set a limit lower than "available disk space / size of largest repository", which reduces it to this deadlock issue.
Broadly, two issues here: