1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-04 20:52:43 +01:00
Commit graph

3 commits

Author SHA1 Message Date
epriestley
6dc582f459 Make HarbormasterBuild a better source of truth about restarting/resuming/stopping
Summary: Ref T1049. The logic in the BuildEngine is a little different from the logic on the Build itself. Make these more consistent, and make queued commands more private.

Test Plan: Restarted, stopped, and resumed a build.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7897
2014-01-06 14:11:59 -08:00
epriestley
1786093c6e 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 12:32:20 -08:00
epriestley
4d5e8a149a Split Harbormaster workers apart so build steps can run in parallel
Summary:
Ref T1049. Currently, the Harbormaster worker looks like this:

  foreach (step) {
    run_step(step);
  }

This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does:

  update_build();

(We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.)

The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build:

  run_one_step(step);
  update_build();

The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly:

  figure_out_overall_status_of_all_steps();
  if (build is done) { done(); }
  if (build is fail) { fail(); }
  foreach (step that is ready to run) {
    queue_target_worker_for_step(step);
  }

So, overall:

  - The part of the code that updates Builds is completely separated from the part of the code that updates Targets.
  - Targets can run in parallel.

Test Plan:
  - Ran a bunch of builds via `bin/harbormaster build`.
  - Ran a bunch of builds via web UI.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 12:32:10 -08:00