My company was a loving user of Phabricator (local server!) for over 10 years. I still fondly remember the discussions here and talking through new applications, testing changes, and so much more. I know that the use of this tool permanently shaped hundreds of engineers' views on code quality, review, the software development lifecycle, and so on. It will be missed.

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.

@epriestley are code contributions no longer accepted? We don't consider this something related to a bug report per se.

Get local issues with unit tests corrected

Thanks. Deployed just now and confirmed working.

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.

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.

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.

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.

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.

object 78daf8de9fe15dce0b4d0e1945a57c778e0536d7
type tag
tag v2.11.1
tagger Test User <test@test.com> 1413916998 -0400

tagging v2.11.1

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.

Excellent, thanks for following up! I am glad it wasn't just some strange issue for just us.

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:

For example:

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.

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.

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.

@jparise this is fixed now: https://github.com/imobile3/cassowary/commit/dbee6144701519938c6845c546f4aa7bf1df3f62

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.

--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.

Confirmed working for our users.

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.

Confirmed working, thanks!

I saw a tweet with a shirt photo, excited to potentially get mine one day!

Confirmed, operations such as svn mv work correctly now.

Unfortunately it doesn't seem to have fixed it, despite our setup and 'arc which' the diffs themselves don't have Repository set.

Agreed. At least in our use cases the task will have a priority and having column moves change that will almost always be unintended.

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.

A header color and replacement top left logo are all we're really looking for.

Now that the first version is behind us, our instance at least is most interested in something like: