Pursue using the infrastructure in D11419 instead.

We're still hitting scenarios where we need the ability to explicitly abort a build (without restarting it). This scenario is where a long-running deployment is currently executing, a bug has been found, and we need to abort the current deployment so we can run out the one with the bug fix.

We don't know exactly how much demand we'll have from existing installs vs new installs, so we aren't putting a lot of resources into import tools up front. For example, we've heard from a number of people that they'd use Phabricator if a hosted version was available, so presumably they don't need import tools.

+1 for workboard by default if initialized, profile otherwise.

As a heads up, when Harbormaster is available for Phacility customers, I highly recommend running those daemon tasks on a different tier. Long running tasks can easily queue up all available taskmaster daemons, and at work we have to run about 50 or so daemons to keep up with peak load (because of the way taskmasters work at the moment, there's no way we can shift only and all of the Harbormaster tasks onto a different set of machines).

Here's an implementation of a web sockets server in PHP: https://github.com/hach-que/Omni/blob/master/src/pipe/WebSocketEndpoint.php

You should install Phabricator using the instructions under https://secure.phabricator.com/book/phabricator/article/installation_guide/#installing-required-comp as that FreeBSD Phabricator package isn't official (as per T4200).

The build locations are configured in Drydock on the host blueprints you have configured.

We had the fix for large queues applied.

It looks like they don't actually fail forever, but with 20k commit tasks in the queue it still takes ages to go through each of them only to discover that they're no longer relevant.

I just clicked the drop down on your comment and selected "View Edit History". The comment also shows "Edited" on it.

We never implemented this locally.

Generally this can be implemented as lint rules (with a custom linter) if you're interested in showing architectural issues in code reviews.

Won't be able to re-upgrade and test that commit for another 10 hours or so as we're in the middle of migrating Harbormaster build logs for the utf8mb process (I moved the table and wrote a script to migrate the logs while Phabricator is online). Will try tomorrow.

For some weird reason, the behaviour is:

Yeah I was wondering why Harbormaster was removed. You also fubar'd T5821 by the way :)

Placing this back for triage, but I think this should probably be of a reasonably high priority on the Harbormaster roadmap, simply because of the impact it can have in migration and schema upgrade times.

I had to basically rename and recreate harbormaster_buildlogchunk for the utf8mb migration because this table was gigabytes in size.

If you want to offload your builds to Jenkins then you can, using the HTTP request mechanism that is already present. This mechanism works for any build server that accepts HTTP requests to start builds.

I don't have any plans to extend Harbormaster with any build steps for external build servers. My focus is primarily on improving Drydock to allocate hosts so that Harbormaster can be used directly, because I think that's more valuable long term (with external build server support is intended mainly for migration).

If only beers could be purchased with mountain of wealth tokens... :3

secret commits

You'll basically have to maintain any changes yourself as epriestley probably doesn't have time to review feature patches right now. For pretty much any change, epriestley either needs to:

As far as I can tell, all this feature does is cause bug IDs like "ABC-123" in a commit message to be turned into links. It's not integration with an external bug tracker.

Personally I think the different title / issue message cleared up a lot of confusion, because it's now very clear as to what the problem is when the issue pops up.

Phabricator needs the ability to decrypt credentials in background processes and in a non-interactive manner. Thus any key to decrypt a credential would need to be stored at the same level as the Passphrase credential itself, defeating the point of encryption (you can't store the decryption keys as a file outside MySQL because that won't scale for HA).

This sounds like it's the same issue as T1191.

I think it should maybe be:

You can have a single build plan that clones the repo and then runs a script (located in the repo) to do the build, then just apply the same build plan to all repositories via Herald.

Is this warning strong enough?

I also think that explicitly supporting external build servers like Jenkins opens a can of worms where it's basically "please add a build step for every other build server in the known universe", which doesn't seem like a very scalable solution (in particular, Jenkins is okay-ish, but there are definitely build servers out there that have an absolutely horrific design / architecture, and with which integration would be extremely difficult).

We could also make the migration a little bit smarter and only enable harbormaster.installed / drydock.installed if they have build plans / blueprints configured respectively, which should appropriately disable these applications for a bunch of installs that have Beta on but aren't using the applications yet.

I definitely agree we need to do something here. Potentially we could do the same as releeph.installed and use a DB migration to automatically enable harbormaster.installed and drydock.installed for any install that has Beta applications installed?

by numbering hidden transactions and just not showing them

Oh okay, I figured it was the Drydock project, but I didn't have permission to see it. I have tried looking up Drydock in the typeahead, but it doesn't come up.