polite-fountain-28010
03/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-61082
03/24/2023, 1:51 PMpolite-fountain-28010
03/24/2023, 2:10 PM--force-build --force
alert-helicopter-61082
03/24/2023, 2:10 PMswift-garage-61180
03/24/2023, 6:37 PMalert-helicopter-61082
03/24/2023, 6:37 PMswift-garage-61180
03/26/2023, 8:37 PMbuildStatus
events with the following action states: getting-status -> cached -> processing -> ready
.
The idea was for the cached
status to be distinguishable from the ready
status, but it does make for an awkward intermediate state in Cloud (after the cached
event is received but before the processing
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 processing
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?force: boolean
and whether a Deploy is being deployed with sync or local mode.polite-fountain-28010
03/27/2023, 9:55 AMcompletedAt
on an event that was in the outdated
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-61180
03/27/2023, 11:41 AMcompletedAt
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.
The completedAt
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 outdated
or cached
final state, whereas executions emit a ready
or failed
final state).
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-28010
03/27/2023, 2:31 PMcompletedAt
states, depending on what part it's in right now.
Also as you mentioned above, we can emit cached
and still go into processing
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 completedAt
event, or we add some extra property that tells us that the process is fully terminated with a success or error state.alert-helicopter-61082
03/27/2023, 3:26 PMpolite-fountain-28010
03/27/2023, 3:36 PMchilly-gigabyte-83853
03/28/2023, 8:49 AMbrief-restaurant-63679
03/29/2023, 7:52 AMswift-garage-61180
03/29/2023, 3:11 PMbrief-restaurant-63679
03/29/2023, 3:27 PM