But no tests are triggered - its only doing the build ?
Ideally the tests based on Tinman and using common frame works like caliper should be run when code changes are made. Now its not possible to have CI - CD for every commit, but periodic invocation of the CI - CD - benchmark can be done. Unlike other blockchains I think the non-consensus layer of the STEEM code base has large number of operations and rc_plugin is just one of the many components. Honestly I don't see any reason for not capturing the bad user experience by minimal testing itself. Unlike in the past STEEM's own Tinman is again getting some maintenance. Perhaps the community can help with CD infrastructure which will ensure high degree of coverage.
In any case, the blockchain and the ecosystem is not stable enough to meet real world scenarios. Personally I feel relieved as at some point during August I considered and designed a means to store part of a disaster rescue operation to the STEEM blockchain. The requests looked something like below and if we had moved ahead, this could have been a catastrophic scenario as the PDNA (Post Disaster Needs Assessment) is now happening and the STEEM blockchain could have prevented its progress.
Original plan was to put the request_ids and the status updates for the above requests to the blockchain as comments. Further the volunteer assignment.
The document (in progress can be seen here : https://docs.google.com/document/d/1EyypzKjkaREOyZGqXMu542QasPoqg16-2iOS9ALAymM/edit?ts=5bab8943#heading=h.h8bplm64d1o8 )
So, for STEEM its important that usability and reliability is ensured and it stays up irrespective of the HF (hard freeze) or otherwise. There is tremendous potential for this chain to become a public general purpose chain for the storage of immutable data and I hope STEEM succeeds in ensuring reliability before SMT, communities and everything else.