Probably not enough consensus for a mass edit. Best we can do is case-by-case fixes reading warn reports.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 5 2024
Any other test plan suggested? Current ones: delete simple milestone, delete project with milestone, delete a project with sub-projects, delete a sub-project, ecc.
Nov 2 2024
One weird observation:
helping reviewers, adding comment on future export possibility
fix lint, happy review
it works!
Nov 1 2024
This very patch got deployed on our rather active downstream instance 10 days ago. I have not heard complaints and I've seen tasks and task comments (replies) created via email, so I'm now pretty confident that it does what it should. Thus I'm going to merge it to reduce technical debt a bit more in Phorge.
Oct 31 2024
Oct 30 2024
add extra escape
OMG IT WORKS
Oct 29 2024
Thanks. Seems good to me since trim($new) does not receive null so cannot create PHP 8.1 problems, since we already execute strlen($new) and mb_strlen($new) and that was not reporting errors in your updated install
@avivey: Would you like to give this another review, once you find some spare time? TIA!
Restore an empty line
I see the API maniphest.createtask is frozen, maybe this can also create tasks: https://we.phorge.it/conduit/method/maniphest.edit/
Oct 28 2024
Oct 27 2024
- APC: Change the setKeys $ttl parameter default to 0
Oct 26 2024
Oct 25 2024
This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.
Oct 24 2024
Think I may have found what is causing this. We had a few repositories that auto download/sync from github. The user's key who connects to github was missing so the downloads were giving errors. I think this triggers a memory leak for the php process. Now that I've fixed the key issue no errors now appear and phorge looks to be happier, i.e. memory usage looks minimal all the time (i.e. php-fpm processes using ~100MBytes).
I'm going to keep monitoring for a few weeks.
Here's an example from the log:
Oct 23 2024
(The Arguments have a supports feature for these cases - like https://we.phorge.it/source/arcanist/browse/master/src/workflow/ArcanistLintWorkflow.php$67 . Not sure what it actually does, but 🤷🏻♂️)
In D25823#22043, @avivey wrote:What if the user used the svn checkout svn+ssh://phab@phorge.example.com/source/myrepo/trunk myRepoOnlyTrunk form - are we still able to find the right target when arc browse lol.txt? Is it a common use-case?
Oct 22 2024
I will add a warning about --branch and better management
For testing, I deployed the latest revision of this proposed patch in our downstream instance and created a task via incoming plain text mail with attachments - seems to still work as expected so no obvious breakage (yet): https://phabricator.wikimedia.org/T377859
Fix typo
mimemailparser: Check that PHP mailparse extension is installed
The function name including a negative, “nonempty”, throws me off…
Oct 21 2024
The email body says Herald added a comment.
The email subject line header says [Changed Project Column] (not [Commented On]).
So I wouldn't say it is incorrectly attributed.
AFAIK there are no Herald rules which trigger a separate email notification on its own (but I agree that the described behavior also has confused me in the past) as Herald rules are always triggered by some other previous action.
Try to make this a separate branch