Does not display most recent build when retriggering
flosell opened this issue · comments
Consider this scenario:
- build 4 has successfully run build-steps
foo
andbar
withbar
being afterfoo
in the pipeline - build 5 runs afterwards, also running completing
foo
- Now we retrigger
bar
on build 4 - build 6 appears, with duplicates of the
foo
results. because cctray orders by build-number, cctray now shows build 6 forfoo
when this build 6 never actually ranfoo
but is just there for pipeline consistency. We'd expect build 5 to be the build cctray uses forfoo
.
Possible fix: sort by :first-updated-at
instead of build number.
We could also sort by :most-recent-update-at
but this might lead to strange flapping when two builds run a step at the same time.
Hmm, this is interesting. Is build 6 you retriggering the in-rqp-workspace
? Or some nested step?
Could you post the timestamps (first-updated-at
, most-recent-update-at
) for the build steps that are relevant (e.g. the one you retriggered, its parents, steps near it, ...)? You'll find them on the api/builds/<buildnumber>/
endpoint or by just expanding the complete step result on a build step.
I think only Build 5 and 6 are important:
Build 6 ("retrigger-mock-for-build-number": 5):
- in-rqp-workspace:
** "status": "success"
** "first-updated-at": "2015-09-15T10:40:23.464Z"
** "most-recent-update-at": "2015-09-15T10:57:54.046Z"
Build 5:
- in-rqp-workspace:
** status": "failure"
** "first-updated-at": "2015-09-15T10:40:23.464Z"
** "most-recent-update-at": "2015-09-15T10:45:01.465Z"
If you retrigger build 5 the new build will have the same "first-updated-at" value. You use this parameter to sort the builds.
I think I now reproduced your behavior, it occurs when retriggering a child of in-rqp-workspace
, right? It seems to be caused by a bug in LambdaCD (flosell/lambdacd#56)
Should be fixed in the next release of LambdaCD
perfect, thank you!
I have tried to figure out what step my colleague has trigged but he did not know exactly.