Scenario:
Create a quest Q which depends on CIPD package P at "latest".
An attempt A is created for this quest, which begins by sending execution E1 to swarming. Swarming then runs, and pins "latest" to some non-arbitrary value (say "deadbeef"). The task runs with "deadbeef" until E1 takes a dependency on something. At this point E1 terminates, and A goes into the blocked state. At some point later, A becomes unblocked, and DM sends E2 to swarming. E2 runs, and pins "latest" again, except that this time it pins it to "badc0ffee".
What this practically means is that multiple different versions of the various CIPD packages will be used during the life of a single Attempt, which is counter-intuitive, and could introduce difficult-to-debug problems (e.g. "deadbeef" and "badc0ffee" have different formats for their "state" that carries over from execution to execution).
To counteract this, the swarming distributor should remember the pinning resolutions that it makes and re-use them from execution to execution of the same attempt.
Plan:
* swarming's client exposes these resolutions as part of the task metadata
* dm+swarming distributor implementation reads this metadata as part of the GetStatus call and records it in the execution state when the execution finishes.
* dm+swarming use the recorded pins when building new executions (e.g. if "PreviousState" includes cipd resolutions, use them).
Comment 1 by iannucci@chromium.org
, Aug 22 2016Status: Started (was: Untriaged)