2014-01-06 21:32:10 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Moves a build forward by queuing build tasks, canceling or restarting the
|
|
|
|
* build, or failing it in response to task failures.
|
|
|
|
*/
|
|
|
|
final class HarbormasterBuildEngine extends Phobject {
|
|
|
|
|
|
|
|
private $build;
|
|
|
|
private $viewer;
|
|
|
|
private $newBuildTargets = array();
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
private $artifactReleaseQueue = array();
|
2014-04-18 01:01:16 +02:00
|
|
|
private $forceBuildableUpdate;
|
|
|
|
|
|
|
|
public function setForceBuildableUpdate($force_buildable_update) {
|
|
|
|
$this->forceBuildableUpdate = $force_buildable_update;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function shouldForceBuildableUpdate() {
|
|
|
|
return $this->forceBuildableUpdate;
|
|
|
|
}
|
2014-01-06 21:32:10 +01:00
|
|
|
|
|
|
|
public function queueNewBuildTarget(HarbormasterBuildTarget $target) {
|
|
|
|
$this->newBuildTargets[] = $target;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getNewBuildTargets() {
|
|
|
|
return $this->newBuildTargets;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setViewer(PhabricatorUser $viewer) {
|
|
|
|
$this->viewer = $viewer;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getViewer() {
|
|
|
|
return $this->viewer;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setBuild(HarbormasterBuild $build) {
|
|
|
|
$this->build = $build;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getBuild() {
|
|
|
|
return $this->build;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function continueBuild() {
|
2021-07-15 19:44:15 +02:00
|
|
|
$viewer = $this->getViewer();
|
2014-01-06 21:32:10 +01:00
|
|
|
$build = $this->getBuild();
|
|
|
|
|
|
|
|
$lock_key = 'harbormaster.build:'.$build->getID();
|
|
|
|
$lock = PhabricatorGlobalLock::newLock($lock_key)->lock(15);
|
|
|
|
|
|
|
|
$build->reload();
|
2014-04-18 01:01:16 +02:00
|
|
|
$old_status = $build->getBuildStatus();
|
2014-01-06 21:32:10 +01:00
|
|
|
|
|
|
|
try {
|
|
|
|
$this->updateBuild($build);
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
// If any exception is raised, the build is marked as a failure and the
|
|
|
|
// exception is re-thrown (this ensures we don't leave builds in an
|
|
|
|
// inconsistent state).
|
2016-07-31 16:56:31 +02:00
|
|
|
$build->setBuildStatus(HarbormasterBuildStatus::STATUS_ERROR);
|
2014-01-06 21:32:10 +01:00
|
|
|
$build->save();
|
|
|
|
|
|
|
|
$lock->unlock();
|
2014-08-12 01:15:16 +02:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$build->releaseAllArtifacts($viewer);
|
2014-08-12 01:15:16 +02:00
|
|
|
|
2014-01-06 21:32:10 +01:00
|
|
|
throw $ex;
|
|
|
|
}
|
|
|
|
|
|
|
|
$lock->unlock();
|
|
|
|
|
|
|
|
// NOTE: We queue new targets after releasing the lock so that in-process
|
|
|
|
// execution via `bin/harbormaster` does not reenter the locked region.
|
|
|
|
foreach ($this->getNewBuildTargets() as $target) {
|
|
|
|
$task = PhabricatorWorker::scheduleTask(
|
|
|
|
'HarbormasterTargetWorker',
|
|
|
|
array(
|
|
|
|
'targetID' => $target->getID(),
|
2015-11-22 23:17:04 +01:00
|
|
|
),
|
|
|
|
array(
|
|
|
|
'objectPHID' => $target->getPHID(),
|
2014-01-06 21:32:10 +01:00
|
|
|
));
|
|
|
|
}
|
2014-04-18 01:01:16 +02:00
|
|
|
|
|
|
|
// If the build changed status, we might need to update the overall status
|
|
|
|
// on the buildable.
|
|
|
|
$new_status = $build->getBuildStatus();
|
|
|
|
if ($new_status != $old_status || $this->shouldForceBuildableUpdate()) {
|
|
|
|
$this->updateBuildable($build->getBuildable());
|
|
|
|
}
|
2014-08-12 01:15:16 +02:00
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
$this->releaseQueuedArtifacts();
|
|
|
|
|
2014-08-12 01:15:16 +02:00
|
|
|
// If we are no longer building for any reason, release all artifacts.
|
|
|
|
if (!$build->isBuilding()) {
|
2021-07-15 19:44:15 +02:00
|
|
|
$build->releaseAllArtifacts($viewer);
|
2014-08-12 01:15:16 +02:00
|
|
|
}
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
private function updateBuild(HarbormasterBuild $build) {
|
2021-07-15 19:44:15 +02:00
|
|
|
$viewer = $this->getViewer();
|
2015-09-21 21:07:24 +02:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$content_source = PhabricatorContentSource::newForSource(
|
|
|
|
PhabricatorDaemonContentSource::SOURCECONST);
|
2014-01-06 21:32:10 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$acting_phid = $viewer->getPHID();
|
|
|
|
if (!$acting_phid) {
|
|
|
|
$acting_phid = id(new PhabricatorHarbormasterApplication())->getPHID();
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
}
|
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$editor = $build->getApplicationTransactionEditor()
|
|
|
|
->setActor($viewer)
|
|
|
|
->setActingAsPHID($acting_phid)
|
|
|
|
->setContentSource($content_source)
|
|
|
|
->setContinueOnNoEffect(true)
|
|
|
|
->setContinueOnMissingFields(true);
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$xactions = array();
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
|
2021-07-15 20:18:46 +02:00
|
|
|
$message_xaction = HarbormasterBuildMessageTransaction::TRANSACTIONTYPE;
|
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$messages = $build->getUnprocessedMessagesForApply();
|
|
|
|
foreach ($messages as $message) {
|
|
|
|
$message_type = $message->getType();
|
2014-01-06 21:32:10 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$xactions[] = $build->getApplicationTransactionTemplate()
|
|
|
|
->setAuthorPHID($message->getAuthorPHID())
|
2021-07-15 20:18:46 +02:00
|
|
|
->setTransactionType($message_xaction)
|
2021-07-15 19:44:15 +02:00
|
|
|
->setNewValue($message_type);
|
|
|
|
}
|
2014-01-29 05:17:03 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
if (!$xactions) {
|
|
|
|
if ($build->isPending()) {
|
|
|
|
// TODO: This should be a transaction.
|
2014-01-29 05:17:03 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
$build->restartBuild($viewer);
|
|
|
|
$build->setBuildStatus(HarbormasterBuildStatus::STATUS_BUILDING);
|
|
|
|
$build->save();
|
|
|
|
}
|
|
|
|
}
|
2014-01-29 05:17:03 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
if ($xactions) {
|
|
|
|
$editor->applyTransactions($build, $xactions);
|
|
|
|
$build->markUnprocessedMessagesAsProcessed();
|
|
|
|
}
|
2014-01-29 05:17:03 +01:00
|
|
|
|
2021-07-15 19:44:15 +02:00
|
|
|
if ($build->getBuildStatus() == HarbormasterBuildStatus::STATUS_BUILDING) {
|
|
|
|
$this->updateBuildSteps($build);
|
|
|
|
}
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
private function updateBuildSteps(HarbormasterBuild $build) {
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
$all_targets = id(new HarbormasterBuildTargetQuery())
|
2014-01-06 21:32:10 +01:00
|
|
|
->setViewer($this->getViewer())
|
|
|
|
->withBuildPHIDs(array($build->getPHID()))
|
2014-08-21 14:55:24 +02:00
|
|
|
->withBuildGenerations(array($build->getBuildGeneration()))
|
2014-01-06 21:32:10 +01:00
|
|
|
->execute();
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
$this->updateWaitingTargets($all_targets);
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
$targets = mgroup($all_targets, 'getBuildStepPHID');
|
2014-01-06 21:32:10 +01:00
|
|
|
|
|
|
|
$steps = id(new HarbormasterBuildStepQuery())
|
|
|
|
->setViewer($this->getViewer())
|
|
|
|
->withBuildPlanPHIDs(array($build->getBuildPlan()->getPHID()))
|
|
|
|
->execute();
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
$steps = mpull($steps, null, 'getPHID');
|
2014-01-06 21:32:10 +01:00
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
// Identify steps which are in various states.
|
2014-01-06 21:32:10 +01:00
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$queued = array();
|
|
|
|
$underway = array();
|
|
|
|
$waiting = array();
|
2014-01-06 21:32:10 +01:00
|
|
|
$complete = array();
|
|
|
|
$failed = array();
|
|
|
|
foreach ($steps as $step) {
|
|
|
|
$step_targets = idx($targets, $step->getPHID(), array());
|
|
|
|
|
|
|
|
if ($step_targets) {
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$is_queued = false;
|
|
|
|
|
|
|
|
$is_underway = false;
|
|
|
|
foreach ($step_targets as $target) {
|
|
|
|
if ($target->isUnderway()) {
|
|
|
|
$is_underway = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$is_waiting = false;
|
|
|
|
foreach ($step_targets as $target) {
|
|
|
|
if ($target->isWaiting()) {
|
|
|
|
$is_waiting = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-06 21:32:10 +01:00
|
|
|
$is_complete = true;
|
|
|
|
foreach ($step_targets as $target) {
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
if (!$target->isComplete()) {
|
2014-01-06 21:32:10 +01:00
|
|
|
$is_complete = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$is_failed = false;
|
|
|
|
foreach ($step_targets as $target) {
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
if ($target->isFailed()) {
|
2014-01-06 21:32:10 +01:00
|
|
|
$is_failed = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$is_queued = true;
|
|
|
|
$is_underway = false;
|
|
|
|
$is_waiting = false;
|
2014-01-06 21:32:10 +01:00
|
|
|
$is_complete = false;
|
|
|
|
$is_failed = false;
|
|
|
|
}
|
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
if ($is_queued) {
|
|
|
|
$queued[$step->getPHID()] = true;
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
if ($is_underway) {
|
|
|
|
$underway[$step->getPHID()] = true;
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($is_waiting) {
|
|
|
|
$waiting[$step->getPHID()] = true;
|
|
|
|
}
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
|
|
|
|
if ($is_complete) {
|
|
|
|
$complete[$step->getPHID()] = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($is_failed) {
|
|
|
|
$failed[$step->getPHID()] = true;
|
|
|
|
}
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
2014-01-13 21:21:49 +01:00
|
|
|
// If any step failed, fail the whole build, then bail.
|
|
|
|
if (count($failed)) {
|
2016-07-31 16:56:31 +02:00
|
|
|
$build->setBuildStatus(HarbormasterBuildStatus::STATUS_FAILED);
|
2014-01-06 21:32:10 +01:00
|
|
|
$build->save();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-01-13 21:21:49 +01:00
|
|
|
// If every step is complete, we're done with this build. Mark it passed
|
|
|
|
// and bail.
|
|
|
|
if (count($complete) == count($steps)) {
|
2016-07-31 16:56:31 +02:00
|
|
|
$build->setBuildStatus(HarbormasterBuildStatus::STATUS_PASSED);
|
2014-01-06 21:32:10 +01:00
|
|
|
$build->save();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
// Release any artifacts which are not inputs to any remaining build
|
|
|
|
// step. We're done with these, so something else is free to use them.
|
|
|
|
$ongoing_phids = array_keys($queued + $waiting + $underway);
|
|
|
|
$ongoing_steps = array_select_keys($steps, $ongoing_phids);
|
|
|
|
$this->releaseUnusedArtifacts($all_targets, $ongoing_steps);
|
|
|
|
|
2014-01-06 21:32:10 +01:00
|
|
|
// Identify all the steps which are ready to run (because all their
|
2014-07-23 02:03:09 +02:00
|
|
|
// dependencies are complete).
|
2014-01-06 21:32:10 +01:00
|
|
|
|
|
|
|
$runnable = array();
|
|
|
|
foreach ($steps as $step) {
|
2014-07-31 03:39:49 +02:00
|
|
|
$dependencies = $step->getStepImplementation()->getDependencies($step);
|
2014-01-06 21:32:10 +01:00
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
if (isset($queued[$step->getPHID()])) {
|
2014-01-06 21:32:10 +01:00
|
|
|
$can_run = true;
|
|
|
|
foreach ($dependencies as $dependency) {
|
2014-07-31 03:39:49 +02:00
|
|
|
if (empty($complete[$dependency])) {
|
2014-01-06 21:32:10 +01:00
|
|
|
$can_run = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($can_run) {
|
|
|
|
$runnable[] = $step;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
if (!$runnable && !$waiting && !$underway) {
|
2014-07-31 03:39:49 +02:00
|
|
|
// This means the build is deadlocked, and the user has configured
|
|
|
|
// circular dependencies.
|
2016-07-31 16:56:31 +02:00
|
|
|
$build->setBuildStatus(HarbormasterBuildStatus::STATUS_DEADLOCKED);
|
2014-01-06 21:32:10 +01:00
|
|
|
$build->save();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($runnable as $runnable_step) {
|
|
|
|
$target = HarbormasterBuildTarget::initializeNewBuildTarget(
|
|
|
|
$build,
|
Replace "Cancel Build" with "Stop", "Resume" and "Restart"
Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.
When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.
Test Plan:
- Created a plan which runs "sleep 2" a bunch of times in a row.
- Stopped, resumed, and restarted it.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1049
Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
|
|
|
$runnable_step,
|
2014-01-06 21:32:10 +01:00
|
|
|
$build->retrieveVariablesFromBuild());
|
|
|
|
$target->save();
|
|
|
|
|
|
|
|
$this->queueNewBuildTarget($target);
|
|
|
|
}
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
/**
|
|
|
|
* Release any artifacts which aren't used by any running or waiting steps.
|
|
|
|
*
|
|
|
|
* This releases artifacts as soon as they're no longer used. This can be
|
|
|
|
* particularly relevant when a build uses multiple hosts since it returns
|
|
|
|
* hosts to the pool more quickly.
|
|
|
|
*
|
|
|
|
* @param list<HarbormasterBuildTarget> Targets in the build.
|
|
|
|
* @param list<HarbormasterBuildStep> List of running and waiting steps.
|
|
|
|
* @return void
|
|
|
|
*/
|
|
|
|
private function releaseUnusedArtifacts(array $targets, array $steps) {
|
|
|
|
assert_instances_of($targets, 'HarbormasterBuildTarget');
|
|
|
|
assert_instances_of($steps, 'HarbormasterBuildStep');
|
|
|
|
|
|
|
|
if (!$targets || !$steps) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$target_phids = mpull($targets, 'getPHID');
|
|
|
|
|
|
|
|
$artifacts = id(new HarbormasterBuildArtifactQuery())
|
|
|
|
->setViewer($this->getViewer())
|
|
|
|
->withBuildTargetPHIDs($target_phids)
|
|
|
|
->withIsReleased(false)
|
|
|
|
->execute();
|
|
|
|
if (!$artifacts) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Collect all the artifacts that remaining build steps accept as inputs.
|
|
|
|
$must_keep = array();
|
|
|
|
foreach ($steps as $step) {
|
|
|
|
$inputs = $step->getStepImplementation()->getArtifactInputs();
|
|
|
|
foreach ($inputs as $input) {
|
|
|
|
$artifact_key = $input['key'];
|
|
|
|
$must_keep[$artifact_key] = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Queue unreleased artifacts which no remaining step uses for immediate
|
|
|
|
// release.
|
|
|
|
foreach ($artifacts as $artifact) {
|
|
|
|
$key = $artifact->getArtifactKey();
|
|
|
|
if (isset($must_keep[$key])) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
$this->artifactReleaseQueue[] = $artifact;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
/**
|
|
|
|
* Process messages which were sent to these targets, kicking applicable
|
|
|
|
* targets out of "Waiting" and into either "Passed" or "Failed".
|
|
|
|
*
|
|
|
|
* @param list<HarbormasterBuildTarget> List of targets to process.
|
|
|
|
* @return void
|
|
|
|
*/
|
|
|
|
private function updateWaitingTargets(array $targets) {
|
|
|
|
assert_instances_of($targets, 'HarbormasterBuildTarget');
|
|
|
|
|
|
|
|
// We only care about messages for targets which are actually in a waiting
|
|
|
|
// state.
|
|
|
|
$waiting_targets = array();
|
|
|
|
foreach ($targets as $target) {
|
|
|
|
if ($target->isWaiting()) {
|
|
|
|
$waiting_targets[$target->getPHID()] = $target;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$waiting_targets) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$messages = id(new HarbormasterBuildMessageQuery())
|
|
|
|
->setViewer($this->getViewer())
|
2018-02-12 19:16:23 +01:00
|
|
|
->withReceiverPHIDs(array_keys($waiting_targets))
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
->withConsumed(false)
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
foreach ($messages as $message) {
|
2018-02-12 19:16:23 +01:00
|
|
|
$target = $waiting_targets[$message->getReceiverPHID()];
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
|
|
|
|
switch ($message->getType()) {
|
2015-08-04 22:05:52 +02:00
|
|
|
case HarbormasterMessageType::MESSAGE_PASS:
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$new_status = HarbormasterBuildTarget::STATUS_PASSED;
|
|
|
|
break;
|
2015-08-04 22:05:52 +02:00
|
|
|
case HarbormasterMessageType::MESSAGE_FAIL:
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$new_status = HarbormasterBuildTarget::STATUS_FAILED;
|
|
|
|
break;
|
2015-08-04 22:05:52 +02:00
|
|
|
case HarbormasterMessageType::MESSAGE_WORK:
|
|
|
|
default:
|
|
|
|
$new_status = null;
|
|
|
|
break;
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($new_status !== null) {
|
|
|
|
$message->setIsConsumed(true);
|
|
|
|
$message->save();
|
|
|
|
|
|
|
|
$target->setTargetStatus($new_status);
|
2015-06-21 22:45:38 +02:00
|
|
|
|
|
|
|
if ($target->isComplete()) {
|
|
|
|
$target->setDateCompleted(PhabricatorTime::getNow());
|
|
|
|
}
|
|
|
|
|
Allow Harbormaster build targets to wait for messages
Summary:
This hooks up all the pieces of the build pipeline so `harbormaster.sendmessage` actually works. Particularly:
- Candidate build steps (i.e., those which interact with external systems) can now "Wait for Message". This pauses them indefinitely when they complete, until something calls `harbormaster.sendmessage`.
- After processing a target, we check if we should move it to PASSED or WAITING.
- Before updating a build, we move WAITING targets with pending messages to either PASSED or FAILED.
- I added an explicit "Building" state, which doesn't affect workflows but communicates more information to human users.
A big part of this is avoiding races. I believe we get the correct behavior no matter which order events occur in:
- We update builds after targets complete and after we receive messages, so we're guaranteed to update once both these conditions are true. This means messages can't be lost (even if they arrive before a build completes).
- The minor changes to the build engine logic mean that firing additional build updates is always safe, no matter what the current state of the build is.
- The build itself is protected by a lock in the build engine.
- The target is not covered by an explicit lock, but for all states only the engine (waiting) //or// the worker (all other states) can interact with it. All of the interactions also move the target state forward to the same destination and have no other side effects.
- Messages are only consumed inside the engine lock, so they don't need an explicit lock.
Test Plan:
- Made an HTTP request wait after completion, then ran a pile of builds through it using `bin/harbormaster build` and the web UI.
- Passed and failed message-awaiting builds with `harbormaster.sendmessage`.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, zeeg
Differential Revision: https://secure.phabricator.com/D8788
2014-04-16 22:01:46 +02:00
|
|
|
$target->save();
|
|
|
|
}
|
|
|
|
}
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|
|
|
|
|
2014-04-18 01:01:16 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Update the overall status of the buildable this build is attached to.
|
|
|
|
*
|
|
|
|
* After a build changes state (for example, passes or fails) it may affect
|
|
|
|
* the overall state of the associated buildable. Compute the new aggregate
|
|
|
|
* state and save it on the buildable.
|
|
|
|
*
|
|
|
|
* @param HarbormasterBuild The buildable to update.
|
|
|
|
* @return void
|
|
|
|
*/
|
2018-02-12 20:28:13 +01:00
|
|
|
public function updateBuildable(HarbormasterBuildable $buildable) {
|
2014-04-18 01:04:14 +02:00
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
2014-04-18 01:01:16 +02:00
|
|
|
$lock_key = 'harbormaster.buildable:'.$buildable->getID();
|
|
|
|
$lock = PhabricatorGlobalLock::newLock($lock_key)->lock(15);
|
|
|
|
|
|
|
|
$buildable = id(new HarbormasterBuildableQuery())
|
2014-04-18 01:04:14 +02:00
|
|
|
->setViewer($viewer)
|
2014-04-18 01:01:16 +02:00
|
|
|
->withIDs(array($buildable->getID()))
|
|
|
|
->needBuilds(true)
|
|
|
|
->executeOne();
|
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
$messages = id(new HarbormasterBuildMessageQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withReceiverPHIDs(array($buildable->getPHID()))
|
|
|
|
->withConsumed(false)
|
|
|
|
->execute();
|
2016-08-31 23:35:57 +02:00
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
$done_preparing = false;
|
2018-02-12 21:03:56 +01:00
|
|
|
$update_container = false;
|
2018-02-12 20:28:13 +01:00
|
|
|
foreach ($messages as $message) {
|
|
|
|
switch ($message->getType()) {
|
|
|
|
case HarbormasterMessageType::BUILDABLE_BUILD:
|
|
|
|
$done_preparing = true;
|
|
|
|
break;
|
2018-02-12 21:03:56 +01:00
|
|
|
case HarbormasterMessageType::BUILDABLE_CONTAINER:
|
|
|
|
$update_container = true;
|
|
|
|
break;
|
2018-02-12 20:28:13 +01:00
|
|
|
default:
|
|
|
|
break;
|
2016-08-31 23:35:57 +02:00
|
|
|
}
|
2018-02-12 20:28:13 +01:00
|
|
|
|
|
|
|
$message
|
|
|
|
->setIsConsumed(true)
|
|
|
|
->save();
|
2014-04-18 01:01:16 +02:00
|
|
|
}
|
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
// If we received a "build" command, all builds are scheduled and we can
|
|
|
|
// move out of "preparing" into "building".
|
|
|
|
if ($done_preparing) {
|
|
|
|
if ($buildable->isPreparing()) {
|
|
|
|
$buildable
|
|
|
|
->setBuildableStatus(HarbormasterBuildableStatus::STATUS_BUILDING)
|
|
|
|
->save();
|
|
|
|
}
|
2014-04-18 01:01:16 +02:00
|
|
|
}
|
|
|
|
|
2018-02-12 21:03:56 +01:00
|
|
|
// If we've been informed that the container for the buildable has
|
|
|
|
// changed, update it.
|
|
|
|
if ($update_container) {
|
|
|
|
$object = id(new PhabricatorObjectQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withPHIDs(array($buildable->getBuildablePHID()))
|
|
|
|
->executeOne();
|
|
|
|
if ($object) {
|
|
|
|
$buildable
|
|
|
|
->setContainerPHID($object->getHarbormasterContainerPHID())
|
|
|
|
->save();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$old = clone $buildable;
|
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
// Don't update the buildable status if we're still preparing builds: more
|
|
|
|
// builds may still be scheduled shortly, so even if every build we know
|
|
|
|
// about so far has passed, that doesn't mean the buildable has actually
|
|
|
|
// passed everything it needs to.
|
|
|
|
|
|
|
|
if (!$buildable->isPreparing()) {
|
2019-02-28 22:19:21 +01:00
|
|
|
$behavior_key = HarbormasterBuildPlanBehavior::BEHAVIOR_BUILDABLE;
|
|
|
|
$behavior = HarbormasterBuildPlanBehavior::getBehavior($behavior_key);
|
|
|
|
|
|
|
|
$key_never = HarbormasterBuildPlanBehavior::BUILDABLE_NEVER;
|
|
|
|
$key_building = HarbormasterBuildPlanBehavior::BUILDABLE_IF_BUILDING;
|
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
$all_pass = true;
|
|
|
|
$any_fail = false;
|
|
|
|
foreach ($buildable->getBuilds() as $build) {
|
2019-02-28 22:19:21 +01:00
|
|
|
$plan = $build->getBuildPlan();
|
|
|
|
$option = $behavior->getPlanOption($plan);
|
|
|
|
$option_key = $option->getKey();
|
|
|
|
|
|
|
|
$is_never = ($option_key === $key_never);
|
|
|
|
$is_building = ($option_key === $key_building);
|
|
|
|
|
|
|
|
// If this build "Never" affects the buildable, ignore it.
|
|
|
|
if ($is_never) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If this build affects the buildable "If Building", but is already
|
|
|
|
// complete, ignore it.
|
|
|
|
if ($is_building && $build->isComplete()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
if (!$build->isPassed()) {
|
|
|
|
$all_pass = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($build->isComplete() && !$build->isPassed()) {
|
|
|
|
$any_fail = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($any_fail) {
|
|
|
|
$new_status = HarbormasterBuildableStatus::STATUS_FAILED;
|
|
|
|
} else if ($all_pass) {
|
|
|
|
$new_status = HarbormasterBuildableStatus::STATUS_PASSED;
|
|
|
|
} else {
|
|
|
|
$new_status = HarbormasterBuildableStatus::STATUS_BUILDING;
|
|
|
|
}
|
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$did_update = ($old->getBuildableStatus() !== $new_status);
|
2018-02-12 20:28:13 +01:00
|
|
|
if ($did_update) {
|
|
|
|
$buildable->setBuildableStatus($new_status);
|
|
|
|
$buildable->save();
|
|
|
|
}
|
2014-04-18 01:01:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$lock->unlock();
|
2014-04-18 01:04:14 +02:00
|
|
|
|
2018-02-12 20:28:13 +01:00
|
|
|
// Don't publish anything if we're still preparing builds.
|
|
|
|
if ($buildable->isPreparing()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$this->publishBuildable($old, $buildable);
|
|
|
|
}
|
2014-04-18 01:04:14 +02:00
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
public function publishBuildable(
|
|
|
|
HarbormasterBuildable $old,
|
|
|
|
HarbormasterBuildable $new) {
|
2014-04-18 01:04:14 +02:00
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$viewer = $this->getViewer();
|
2015-06-25 19:05:37 +02:00
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
// Publish the buildable. We publish buildables even if they haven't
|
|
|
|
// changed status in Harbormaster because applications may care about
|
|
|
|
// different things than Harbormaster does. For example, Differential
|
|
|
|
// does not care about local lint and unit tests when deciding whether
|
|
|
|
// a revision should move out of draft or not.
|
|
|
|
|
|
|
|
// NOTE: We're publishing both automatic and manual buildables. Buildable
|
|
|
|
// objects should generally ignore manual buildables, but it's up to them
|
|
|
|
// to decide.
|
2015-06-25 19:05:37 +02:00
|
|
|
|
|
|
|
$object = id(new PhabricatorObjectQuery())
|
|
|
|
->setViewer($viewer)
|
2018-04-03 14:48:40 +02:00
|
|
|
->withPHIDs(array($new->getBuildablePHID()))
|
2015-06-25 19:05:37 +02:00
|
|
|
->executeOne();
|
|
|
|
if (!$object) {
|
|
|
|
return;
|
2014-04-18 01:04:14 +02:00
|
|
|
}
|
2015-06-25 19:05:37 +02:00
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$engine = HarbormasterBuildableEngine::newForObject($object, $viewer);
|
2017-01-04 20:31:44 +01:00
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$daemon_source = PhabricatorContentSource::newForSource(
|
|
|
|
PhabricatorDaemonContentSource::SOURCECONST);
|
2015-06-25 19:05:37 +02:00
|
|
|
|
|
|
|
$harbormaster_phid = id(new PhabricatorHarbormasterApplication())
|
|
|
|
->getPHID();
|
|
|
|
|
2018-04-03 14:48:40 +02:00
|
|
|
$engine
|
2015-06-25 19:05:37 +02:00
|
|
|
->setActingAsPHID($harbormaster_phid)
|
|
|
|
->setContentSource($daemon_source)
|
2018-04-03 14:48:40 +02:00
|
|
|
->publishBuildable($old, $new);
|
2014-04-18 01:01:16 +02:00
|
|
|
}
|
|
|
|
|
In Harbormaster, release artifacts as soon as no waiting/running build steps will use them
Summary:
Ref T11153. If you have a build plan like this:
- Lease machine A.
- Lease machine B.
- Run client-tests on machine A.
- Run server-tests on machine B.
...and we get machine A quickly, then finish the tests, we currently do not release machine A until the whole plan finishes.
In the best case, this wastes resources (something else could be using that machine for a while).
In a worse case, this wastes a lot of resources (if machine B is slow to acquire, or the server tests are much slower than the client tests, machine A will get tied up for a really long time).
In the absolute worst case, this might deadlock things.
Instead, release artifacts as soon as no waiting/running steps take them as inputs. In this case, we'd release machine A as soon as we finished running the client tests.
In the case where machines A and B are resources of the same type, this should prevent deadlocks. In all cases, this should improve build throughput at least somewhat.
Test Plan:
I wrote this build plan which runs a "fast" step (10 seconds) and a "slow" step (120 seconds):
{F1691190}
Before the patch, running this build plan held the lease on the "fast" machine for the full 120 seconds, then released both leases at the same time at the very end.
After this patch, I ran this plan and observed the "fast" lease get released after 10 seconds, while the "slow" lease was held for the full 120.
(Also added some `var_dump()` into things to sanity check the logic; it appeared correct.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11153
Differential Revision: https://secure.phabricator.com/D16145
2016-06-17 22:18:22 +02:00
|
|
|
private function releaseQueuedArtifacts() {
|
|
|
|
foreach ($this->artifactReleaseQueue as $key => $artifact) {
|
|
|
|
$artifact->releaseArtifact();
|
|
|
|
unset($this->artifactReleaseQueue[$key]);
|
|
|
|
}
|
2014-08-12 01:15:16 +02:00
|
|
|
}
|
|
|
|
|
2014-01-06 21:32:10 +01:00
|
|
|
}
|