You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ATM it is tricky to associate state of the badge to the log file(s) to look at.
Yet to figure out how we could achieve that in not too ad-hoc fashion since logs are fetched/removed by con/tinuous. May be shouldn't be removed but "overloaded" in some branch (without history) along side with all the badges (i.e. have per client/run branch to contain badge + log)
@yarikoptic If the logs & badges for a given client are always going to be on the same branch, I don't like the idea of not storing the history. How about creating status-<clientid> branches that contain the badges and logs for the highest-numbered run so far on the respective clients, with normal Git versioning?
the problem with "normal Git versioning" is that the repository would very quickly grow in its size through collecting the history of builds. We could make them into separate (no common root) branches status-<clientid>-<buildid> with status-<clientid> pointing to the same commit of the corresponding build, and then use con/tineous to archive/remove older build branches?
ATM it is tricky to associate state of the badge to the log file(s) to look at.
Yet to figure out how we could achieve that in not too ad-hoc fashion since logs are fetched/removed by con/tinuous. May be shouldn't be removed but "overloaded" in some branch (without history) along side with all the badges (i.e. have per client/run branch to contain badge + log)
WDYT @jwodder ?
The text was updated successfully, but these errors were encountered: