Yes, of course. I apologise. We updated to head today.

The repro case is against this install. :)

Just a question from an observer of this conversation; @hach-que - wouldn't it be possible for Protobuild itself to use a script written in a widely available scripting language, like PHP/Ruby/Python/Bash which does the platform detection, thus allowing it to have pretty much the same build command for all platforms? Or perhaps even wrapping it in Make and require MinGW/Cygwin on Windows?
This is touching on what Google is doing with Bazel and what Facebook is doing with Buck, but taking it even further and having the same tool for all teams and technologies as well.

I apologise for filing issues on it, I know it is against the policy. I've been following Drydock/Harbormaster quite closely and we have been using it for builds for quite a while. Most of the integration you get into Phabricator has been invaluable for us in general. However, the first two outlined issues literally broke all builds for us, and while I understand that you need the agility to be able to break prototype applications, I would hope it is also valuable for you to know how the users who dare to use unsupported applications deal with the changes you make and the problems they encounter, it seems Drydock/Harbormaster in particular is moving towards a more stable place now and the implementations you've landed in with the latest changes look really solid.

In T5508#73739, @mholden wrote:

Just a thought -- when a build is trigged by Herald, could the Herald (or some subset) be passed and available to Harbormaster?

In my current setup, Herald triggers a build when "commit's branches" matches /develop/. If this (and similar) information could be available to Harbormaster, users may find that helpful.

I'd also like to voice my support for this. We have Yubikeys here for MFA and I do use Passphrase quite a lot as well. Right now I've set up the Yubikey to be a Mobile TOTP-provider instead so I can just get a standard Mobile TOTP code to input via a keyboard command. This is rather specific to OSX/Linux and Android, though as it requires an Android phone with an NFC reader to read the shared secret up to give you the TOTP codes if you do not have a computer handy and the keyboard shortcut has a high technical skill level requirement because it means you must be able to grab terminal output and put it on your clip board. The native app does not make it much better than a Mobile TOTP, hence the implementation I've deviced for myself.

This is actually pretty much exactly what we were looking for. Could be cool to add to the incoming email documentation, perhaps? Thank you, none the less. :)

I'm just going to give our use case for being able to disable workboards. We created workboards on some projects where work was done (let's call it Ops), but after some restructuring (yay) the ops department became split into teams. We still want to preserve the Ops tag to show that the work is ops-related, but we are now using #teamawesome workboards instead. Now issues are showing up as on the (backlog) on the ops-project workboard, while they will actually never be moved on that board. It is mainly a cosmetic thing, but it does cause some confusion for our users as well.
It would be cool if you could disable the workboard - the UI for it could just be that you end up on the workboard page with a text saying "This workboard is disabled" and if you have edit permissions on the project you can enable it again. If the workboard is disabled the column assignments would not show up on Maniphest tasks anymore.
We do not really have a need to remove them from the database, though.

Ah, that was an intermediate error that I got when I was trying to solve it. I'll implement the fix that you have in D13335 and it solves the problem I experienced. :)

Ah, to recreate this you only need to add a build plan with a "Lease Host" step and you will get this fatal. The class referenced in the first message in the stack trace will be DrydockConstants and not PhabricatorWorkerArchiveTaskQuery though.

We've also hit this, but we had our SES configured in the EU-west region, I used the diff attached and updated it to the current code base.

Thanks for being so quick!

TESTILYTEST

During diligent testing (the empirically safe amount of 7 commits) in my environment I have not managed to successfully reproduce this since the latest commits. I leave it up to you to decide whether this constitutes enough evidence to close it or not!

No, issue still remains and is rather prevalent. Around 25-50% in my environment.

Gosh darn it. I who'd actually gotten around to making a GIT_TRACE_PACKET = 1 push and managed to reproduce it. I've just now updated to the latest revision and will see if I get it again, though.
Here is the log, for posterity: