- User Since
- May 23 2012, 3:07 PM (390 w, 20 h)
Aug 13 2019
Sep 5 2017
Thanks, been a while since we tried to do this. Bug report submitted at https://discourse.phabricator-community.org/t/inline-comments-not-generated-for-lint-results-when-uploaded-from-windows/377.
Aug 31 2017
@epriestley are code contributions no longer accepted? We don't consider this something related to a bug report per se.
Aug 14 2017
Get local issues with unit tests corrected
Aug 3 2017
Apr 11 2017
Thanks. Deployed just now and confirmed working.
Mar 8 2017
In our case these are commits from landed Differential diffs. Permissions
for the web user are there and correct, but I'm not sure I understand all
the details around the daemon vs. web user, and the daemon is doing the
work for this git commit parser.
Mar 7 2017
Occasionally, even after running the re-parse command, the basics of the commit will import but the content itself will not. A phd restart will almost immediately allow the commit to then import.
More info: the commit contained binary files (executables actually).
We now have one that's failing even when forcing a reparse:
Is there a way to recall the logs from a failing task? Is there any value in providing the logs for the successful task? Not really sure what to say here besides that it's a consistent and random issue on our repositories. When we run the trace, it then "bumps" the task somehow and things succeed, so it would be difficult to provide detail on an error.
Jan 4 2017
This can be closed as invalid (or resolved I guess). Looks like we performed an install and some upgrades at an awkward time when some storage upgrade changes were occurring. We've run several stable branch updates on the install since and it's been fine.
Dec 9 2016
Re-applied the scripts and all is well now. Once another SQL script comes into the stable branch I will run the upgrade again, something must still be off here. For reference, after a pull, daemon stop, etc. we are only running storage upgrade --force -- is this incorrect? Seems to be fine in our other instances, but for this one the scripts are being marked as applied, but they aren't.
Dec 8 2016
Jun 20 2016
That did it, thanks!
Thanks, this is working now.
This is in all likelihood a mistake made forever ago but I'll wait for a potential patch.
tagger Test User <email@example.com> 1413916998 -0400
If it requires us to delete the v2.11.1 tag then so be it, we understand that maybe we did something wild with history in the past but that tag doesn't really give us anything anymore so it can go.
Had to redact a bit:
The repo uses callsign P and refers to Platform.
Feb 10 2016
Jan 26 2016
Jan 21 2016
Nov 21 2015
Excellent, thanks for following up! I am glad it wasn't just some strange issue for just us.
Sep 1 2015
The email itself is isolated to the one action: movement on a workboard. There is a second e-mail however which refers to the closure of a task. The two are effectively grouped together and happened quickly, but two separate emails were sent. The other email's headers:
Aug 31 2015
Jun 25 2015
Confirmed working, thanks! A future request might be to have that range configurable.
Month view is working, stupidity on my part -- didn't switch to the next month!
After digging around this might be a limitation of the "upcoming events" query. We assumed that some views would present at least a minimal number of items, but that query now seems to be more restrictive. That's all this is. Is that timeframe configurable? We reported this because events went missing in some places, but that's just because they're far enough out in time.
Jun 24 2015
Not sure if these sorts of things are placed anywhere special these days but the application of this patch was brutal on our system -- took like 30 minutes on our relatively-decent hardware and MySQL instance. Might be worth warning.
May 8 2015
Good to go now, thanks!
I stand corrected. This still occurs for all-day events.
Not sure if this can be reproduced on your side but the first all-day event I attempted to create on our instance (it was multi-day as well) gave me an "invalid timezone" exception. Apparently "GMT+12" was attempted to be used. I went to try again and succeeded that time.
May 6 2015
Yeah that's what we were doing actually, but given our environment and arcanist's checks regarding the file permissions (that it's 600, etc.) it was messy due to shell restrictions and other stuff where our scripts are running. This will be great for build agents posting back Harbormaster statuses.
Great, thanks. It appears that it does still need the certificate in a .arcrc file somewhere, as we removed that file as part of the above test and received the certificate prompt.
Is the above commit able to be used or are there a few steps to go? Gave it a quick try and it still wanted my bot user to install a certificate despite providing an API token with the above parameter.
May 4 2015
--conduit-token would be the bee's knees for us, managing the .arcrc file with web users, file permissions, and all this other noise is a huge hassle.
Jan 6 2015
Confirmed working for our users.
Sep 3 2014
Aug 4 2014
I can't strictly speak to everything moved in this diff, but applying relationships does work correctly now so it's functionally fine.
Confirmed working now.
Jul 26 2014
Confirmed working, thanks!
Jul 25 2014
Apr 20 2014
I saw a tweet with a shirt photo, excited to potentially get mine one day!
Apr 1 2014
Confirmed, operations such as svn mv work correctly now.
Mar 24 2014
Unfortunately it doesn't seem to have fixed it, despite our setup and 'arc which' the diffs themselves don't have Repository set.
Mar 4 2014
Agreed. At least in our use cases the task will have a priority and having column moves change that will almost always be unintended.
Feb 24 2014
Let's do it with a test repo, I'll execute the commands and see if it gets crazy.
Can you browse via that tag now? We see the hash update but then get a "Failed to look up tag" exception.
Feb 14 2014
Feb 12 2014
Dec 3 2013
A header color and replacement top left logo are all we're really looking for.