polite-fountain-2801003/24/2023, 1:50 PM
ℹ api → Building version v-4a71816b6b...
✔ api → Done (took 0 sec)
ℹ api → File sync to cluster complete
ℹ api → Building image api:v-4a71816b6b...
alert-helicopter-6108203/24/2023, 1:51 PM
polite-fountain-2801003/24/2023, 2:10 PM
alert-helicopter-6108203/24/2023, 2:10 PM
swift-garage-6118003/24/2023, 6:37 PM
alert-helicopter-6108203/24/2023, 6:37 PM
swift-garage-6118003/26/2023, 8:37 PM
events with the following action states:
The idea was for the
getting-status -> cached -> processing -> ready
status to be distinguishable from the
status, but it does make for an awkward intermediate state in Cloud (after the
event is received but before the
event is received).
That is, there's no way for Cloud to know whether the action is complete (and show e.g. a green colour), which is the case for cache hits when not forcing, or whether a
event is expected (which is the case when forcing).
We do need to perform the status check when forcing, since the "process action" handlers receive a status value as a param.
Maybe a good compromise would be to simply not emit status events for the status check action (e.g. "get build status") when the action is being forced?
and whether a Deploy is being deployed with sync or local mode.
polite-fountain-2801003/27/2023, 9:55 AM
on an event that was in the
state, making cloud think that the task is completed, only to then get further events that bring it back into the pending state. We probably shouldn't mark anything as completed if the process still continues on afterwards.
swift-garage-6118003/27/2023, 11:41 AM
timestamp for status events emitted during the "get status" methods—the idea there was to enable Cloud to calculate how long the status checks are taking.
timestamp means: "This status check was completed at" or "This execution was completed at"—whether it was a status check or an execution is clear from the state (status checks emit an
final state, whereas executions emit a
I.e. we want to track both the durations of the status checks and the actual builds/deploy/runs/tests that happen afterwards.
The action state in the event should be enough to disambiguate between those two.
polite-fountain-2801003/27/2023, 2:31 PM
states, depending on what part it's in right now.
Also as you mentioned above, we can emit
and still go into
so it gets even more confusing.
Maybe we can just not emit it as you suggested, or if garden knows that it's still doing more work after, it just doesn't emit a
event, or we add some extra property that tells us that the process is fully terminated with a success or error state.
alert-helicopter-6108203/27/2023, 3:26 PM
polite-fountain-2801003/27/2023, 3:36 PM
chilly-gigabyte-8385303/28/2023, 8:49 AM
brief-restaurant-6367903/29/2023, 7:52 AM
swift-garage-6118003/29/2023, 3:11 PM
brief-restaurant-6367903/29/2023, 3:27 PM